Bonjour,

La première fois que j'ai voulu mettre un capteur surveillant le DHCP de mon réseau local dans ma supervision PRTG, cela n'avait pas marché. Le capteur disait toujours : time out, pas de réponse du serveur DHCP.

J'en avais conclus que j'avais du rater un truc, vu que mon Icotera i4850 faisait le job et PRTG aussi.

J'ai réessayé hier, en changeant de serveur DHCP (routeur asus, puis NAS) et là le capteur DHCP de PRTG marche nickel dans les deux cas.
Ça m'a intrigué et j'ai sniffé les paquets DHCP du PC sur lequel tourne PRTG et ceux de PRTG (pas en même temps).

L'icotera ne fait pas d'OFFER au DISCOVER PRTG, mais il en fait à la demande de la carte réseau du PC.

La seule nuance que j'ai vu dans les deux trames Discover est le port source : 68 pour la carte et 64185 pour PRTG.
Pas vu dans la RFC que le port source était imposé.

Verriez-vous autre chose?

C'est fou comme je tombe toujours sur des trucs chelous! 

Merci pour vos éclairages

Packet comments     dhcp discover de PRTG Frame 1: 590 bytes on wire (4720 bits), 590 bytes captured (4720 bits) on interface \Device\NPF_{4E3B61F6-21CA-44BB-85AF-B6E72F8994D1}, id 0 Ethernet II, Src: PCPartner_79:12:00 (00:01:2e:79:12:00), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Internet Protocol Version 4, Src: 192.168.1.25, Dst: 255.255.255.255 User Datagram Protocol, Src Port: 64185, Dst Port: 67     Source Port: 64185     Destination Port: 67     Length: 556     Checksum: 0xab7e [unverified]     [Checksum Status: Unverified]     [Stream index: 0]     [Timestamps]     UDP payload (548 bytes) Dynamic Host Configuration Protocol (Discover)     Message type: Boot Request (1)     Hardware type: Ethernet (0x01)     Hardware address length: 6     Hops: 0     Transaction ID: 0x00eedc0a     Seconds elapsed: 255     Bootp flags: 0x8000, Broadcast flag (Broadcast)     Client IP address: 0.0.0.0     Your (client) IP address: 0.0.0.0     Next server IP address: 0.0.0.0     Relay agent IP address: 0.0.0.0     Client MAC address: PCPartner_79:12:00 (00:01:2e:79:12:00)     Client hardware address padding: 00000000000000000000     Server host name not given     Boot file name not given     Magic cookie: DHCP     Option: (53) DHCP Message Type (Discover)     Option: (255) End     Padding [truncated]:

Packet comments     dhcp discover PC Frame 1: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{4E3B61F6-21CA-44BB-85AF-B6E72F8994D1}, id 0 Ethernet II, Src: PCPartner_79:12:00 (00:01:2e:79:12:00), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255 User Datagram Protocol, Src Port: 68, Dst Port: 67     Source Port: 68     Destination Port: 67     Length: 308     Checksum: 0xd1b7 [unverified]     [Checksum Status: Unverified]     [Stream index: 0]     [Timestamps]     UDP payload (300 bytes) Dynamic Host Configuration Protocol (Discover)     Message type: Boot Request (1)     Hardware type: Ethernet (0x01)     Hardware address length: 6     Hops: 0     Transaction ID: 0xf8291761     Seconds elapsed: 0     Bootp flags: 0x0000 (Unicast)     Client IP address: 0.0.0.0     Your (client) IP address: 0.0.0.0     Next server IP address: 0.0.0.0     Relay agent IP address: 0.0.0.0     Client MAC address: PCPartner_79:12:00 (00:01:2e:79:12:00)     Client hardware address padding: 00000000000000000000     Server host name not given     Boot file name not given     Magic cookie: DHCP     Option: (53) DHCP Message Type (Discover)     Option: (61) Client identifier     Option: (12) Host Name     Option: (60) Vendor class identifier     Option: (55) Parameter Request List     Option: (255) End     Padding: 0000000000000000000000

Bonjour,

La RFC impose les ports de réception (serveur 67 et client 68).
Je n'ai rien vu concernant les ports d'émission. Les requêtes peuvent donc utiliser n'importe quel port source.

Mon PC Windows fait le DHCP Discover et Request de 68 vers 67 et il y a une règle d'ouverture en ce sens dans le firewall. La réponse de l'Icotera (Offer et Ack) de 67 vers 68
Je regarde ce matin.
Mais si c'est le firewall du PC PRTG, pourquoi mes autres serveurs DHCP répondraient?
Je n'ai le silence suite au Discover qu'avec l'Icotera.
Je soupçonne le firewall de l'Icotera qui n'accepterait les paquets DHCP que si le port source est 68?

Un excès de zèle en quelque sorte.

Edit 10h10 : testé avec le pare-feu windows désactivé : Cela ne change rien.

Bug Icotera?

@Steph: Je pense que tu n'as pas bien compris la citation de Catalyst :

DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68).

Ton client vers le serveur DHCP utilise le port 67 en destination (ok), MAIS les messages dans le sens serveur->toi se font sur le port destination 68.

Autrement dit, tu peux utiliser n'importe quel port _source_ pour la requête (tant que ça rentre dans le 67 en face), OK
MAIS au risque de ne jamais recevoir la réponse, car la réponse t'est renvoyée non pas sur ton port source... mais ton port 68.
Du coup ton PRTG attend une réponse qui n'arrivera jamais s'il n'écoute pas sur le 68.

C'est comme ça que je le comprends.

Une explication de cette restriction au port 68, faite pour éviter les conflits en cas de réponse broadcast.
https://superuser.com/a/931987

Ca explique pourquoi les messages du serveur DHCP vers le client doivent être envoyés au port 68.
Ca n'explique pas pourquoi un "random port" ne peut pas être utilisé dans une requête au serveur, comme celle qu'envoie le PRTG de Steph.
Il est vrai qu'en général, une "réponse" à un datagramme UDP inverse les ports source et destination de la "requête", mais le protocole DHCP est quand même différent (notamment avec ces notions de broadcast).
Je trouve que le RFC 2131 n'est pas assez prescriptif dans sa rédaction.

Je suis spécialiste en détections de trucs idiots.

Du boulot en perspective pour ta reconversion ... dans tout domaine.

Je vois 3 possibilités pour occuper ton week-end :
- demander du support à Icotera (aucune chance, tu te souviens qu'on avait essayé avec bolemo, le gars que j'avais réussi à contacter ne voulait parler qu'aux clients opérateurs)
- demander du support à Paessler. Si tu as la version gratuite, je ne sais pas s'ils te répondront
- écrire un "DHCP sensor" qui "binde" le port source en udp/68

plus la possibilité de fainéant : laisser tomber