La Fibre

Télécom => Réseau => reseau TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: Steph le 01 août 2024 à 22:41:08

Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: Steph le 01 août 2024 à 22:41:08
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
Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: Catalyst le 02 août 2024 à 00:00:23
Bonsoir,

la RFC impose de fait le port 68 :

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).

https://www.rfc-editor.org/rfc/rfc2131#section-4.1

Après, les acteurs respectent ou pas.
Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: Steph le 02 août 2024 à 09:57:46
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?
Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: pju91 le 02 août 2024 à 11:01:42
Citation de: Steph le 02 août 2024 à 09:57:46
Bug Icotera?
Loi de Postel non respectée : "be conservative in what you send, be liberal in what you accept".
Je suis d'accord avec ta lecture du RFC, mais Icotera n'a peut-être pas compris de la même manière.
Il est vrai que la plupart des clients semblent utiliser également 68 comme port source des requêtes vers un serveur DHCP.
Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: Optix le 02 août 2024 à 11:03:34
@Steph: Je pense que tu n'as pas bien compris la citation de Catalyst :

Citer
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.
Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: Catalyst le 02 août 2024 à 11:39:30
Une explication de cette restriction au port 68, faite pour éviter les conflits en cas de réponse broadcast.
https://superuser.com/a/931987

Le pourquoi du comment de ces broadcasts :
https://networkengineering.stackexchange.com/a/41355

Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: pju91 le 02 août 2024 à 12:08:32
Citation de: Catalyst le 02 août 2024 à 11:39:30
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.

Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: Steph le 02 août 2024 à 18:12:34
Citation de: pju91 le 02 août 2024 à 11:01:42
Il est vrai que la plupart des clients semblent utiliser également 68 comme port source des requêtes vers un serveur DHCP.
Oui, j'avais toujours vu 68->67 et 67->68.
Mais pas le discover de PRTG.

Citation de: Optix le 02 août 2024 à 11:03:34
@Steph: Je pense que tu n'as pas bien compris la citation de Catalyst :

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.
Oui, c'est bien ce que j'avais compris. J'avais même relu la partie de RFC citée avant de poster.

Citation de: Optix le 02 août 2024 à 11:03:34
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.
De ce que j'ai pu voir au niveau des paquets, PRTG marche bien. Il émet de 50xxx vers 67 et écoute 68.
PRTG Discover 50xxx -> 67
Routeur DHCP (NAS Synology ou Routeur ASUS) Offer 67->68

Et cela suffit à PRTG pour dire qu'il y un serveur DHCP à telle IP qui a proposé telle adresse.

Apparemment, c'est vraiment l'Icotera qui ne répond jamais au Discover de PRTG, alors qu'il répond aux Discovers qui partent de 68.

Je suis spécialiste en détections de trucs idiots.
Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: pju91 le 03 août 2024 à 10:49:37
Citation de: Steph le 02 août 2024 à 18:12:34
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
Titre: Incompatibilité DHCP entre routeur Icotera et PRTG
Posté par: Steph le 03 août 2024 à 15:37:27
Je vais manquer de courage.  ;)