Réponse DHCP de la box

[ToFoo93]

Ok, merci pour la confirmation, ta formulation m'a fait douter

il y aura un changement de firmware vers la fin d'année en passant sur celui "maison" tu verras si le comportement se poursuit ou pas, mais bon en l'état coté ingénierie c'est conforme (même si je pense ça t'arrange pas), fais nous un UP du fil à l'occasion.

Cdt

[ESTBLC]

Bonjour,

Je suis dans une situation similaire. Mon setup:
- Bbox avec DHCPv4 désactive dans l'interface (ip: 192.168.1.254)
- Raspberry Pi 4 avec dnsmasq, DHCP active (ip: 192.168.1.251)

Tout mes devices Linux (laptop, telephone android) se connectent et recoivent une IP sans souci de la part de mon serveur DHCP.
Cependant tous mes devices Windows mettent plusieurs minutes voire n'arrivent jamais a avoir une IP malgré le fait qu'une IP leur soit propose par le serveur.
J'ai essayer de connecter mon serveur DHCP et un device windows sur un switch sans la Bbox et le problème disparaît, le device accepte une IP sans souci. La seule difference vient du fait que la Bbox ne vient pas envoyer de NAK.

Je vous mets un dump d'un échange vu de mon client windows après avoir release son IP en PJ. Notez les 2 minutes d'attente pour que enfin le client arrive a accepter une IP.

PS: Si on pouvait changer l'IP du serveur DNS advertise par le serveur DHCP de la Bbox, je n'aurais pas eu besoin de mettre en place un serveur DHCP par moi meme.

[Schmurtz]

Situation similaire constatée ici : le DHCP de la Bbox annule systématiquement les requêtes DHCP de nombreux appareils en leur renvoyant une réponse NAK.

"C’est rare que des équipements envoient le Request en Broadcast"

Cette affirmation ne reflète pas la réalité. Rien qu'au sein de mon domicile j'ai constaté que de nombreux appareils ne fonctionnait plus en raison des NAK renvoyés par la BBOX.
3 types d'appareils sont systématiquement impactés à mon domicile et ne fonctionnent carrément plus (les enceintes Sonos, les Rapsberry et les ESP32).

• Certes, les utilisateurs de Raspberry Pi ou de cartes ESP8266/ESP32 représentent probablement une petite fraction des abonnés Bbox. (Quoique avec plus de 60 Millions de Raspberry vendus en un mois en France et en Europe on peut se demander...)
• Certains équipements grand public, comme les enceintes et amplis Sonos envoient systématiquement leur requête DHCP en broadcast. De plus ces appareils ne permettent pas une configuration IP fixe.
• Conséquence : si on utilise son propre serveur DHCP ces devices ne fonctionnent tout simplement plus, leur requête DHCP est systématiquement rejetée par la Bbox, même lorsque le DHCP est censé être désactivé.

Et je ne parle là que de ce que j'ai pu observer à mon domicile, la liste des appareils qui se prennent systématiquement des NAK est sans doutes bien plus longue.
Pour la plupart des utilisateurs confrontés à ce problème, comprendre que la Bbox est bien responsable des problèmes réseaux sur leurs appareils nécessite un diagnostique quasi impossible donc évidemment ils ne se manifesteront jamais ici. Beaucoup remettront en question leur configuration ou leurs appareils avant de se rendre compte s'ils ont de la chance que la source du blocage est la Bbox elle-même. Même si cela concerne probablement "seulement" quelques milliers d’utilisateurs bbox, le problème reste réel et non négligeable.

---

Il est frustrant de diagnostiquer des heures, des jours durant, de devoir dépenser dans du matériel supplémentaire ou bricoler des solutions pour contourner des limitations logicielles volontairement restrictives. Ces contraintes artificielles ne sont pas justifiées par les besoins techniques réels et pénalisent les abonnés BBox. Il est temps que cela change que l'utilisateur puisse faire ses propres choix concernant les DNS et le DHCP quitte à ce que l'initiative de modification soit précédée d'un warning.

Pour soutenir cette requête et manifester votre accord avec ces constats, je vous invite à participer à la discussion ici :
https://www.bbox-mag.fr/forum/viewtopic.php?t=4443

Il serait intéressant d'y centraliser les posts des utilisateurs en détresses en raison de ces limitations plus que contraignantes.
Cela permettrait de montrer le nombre important de personnes affectées et de renforcer la légitimité d’une requête collective auprès de Bouygues, de l’ARCEP et de la CNIL.

[ToFoo93]

Bonsoir

Il ne me semble pas que ça soit un problème mais un choix technique répondant à la norme RFC (faudra retrouver celle en référence car je ne l’ai pas en tête)
Si vous voulez allez aussi loin et by-passer cela il faudrait demander l’ONT et faire fonctionner votre propre routeur.
Pour solliciter l’ARCEP faudrait que l’opérateur enfreigne un principe ce qui n’est pas le cas ici.

Bonnes fêtes

[mvisconte]

Bonjour,

Je répond longtemps après la bagarre, parce que je me suis battu avec ça pendant les vacances.

Je me suis penché sur la réponse technique de 2024, penché sur la RFC (pour référence: https://www.ietf.org/rfc/rfc2131.txt), et je me permet un retour que j'espère constructif

Le fonctionnement décrit dans le post bbox-mag est conforme à la norme DHCP. En effet, dans la trace réseau l’équipement LAN envois le DHCP Request message en Broadcast donc le serveur de l’IAD le reçoit et il répond par un NACK.

C’est rare que des équipements envoient le Request en Broadcast (ça dépend de la config de DHCP client de l’équipement) …

Sur la partie "C’est rare que des équipements envoient le Request en Broadcast", ça me semble aller à l'encontre de la RFC, qui dit, à la section 3.1.3 (la graisse est de moi):

The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and that MAY include other options specifying desired configuration values. The 'requested IP address' option MUST be set to the value of 'yiaddr' in the DHCPOFFER message from the server.

Sur la partie " le serveur de l’IAD le reçoit et il répond par un NACK", ça ne me semble pas non plus conforme à la RFC, section 3.1.4, qui dit:

If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message.

Dans notre cas, la BBOX ne reçoit pas de DHCPREQUEST, je vois bien avec Wireshark qu'elle est broadcast, conformément à la spec, avec l'option DHCP Server Identifier bien renseignée: 192.168.1.233 (l'IP de mon serveur DNS), et pas 192.168.1.254 (l'IP de la box).

La box devrait donc ignorer ces requêtes, qui ne la concernent pas, et en aucun cas envoyer un DHCPNAK, car on ne lui a rien demandé.

Merci pour tout ce qui pourra être fait pour que ça arrive dans les bonnes mains

[ToFoo93]

Bonjour,

Merci pour ton retour, je crois j'ai déjà transmis quels choses d'équivalent à ce sujet mais selon l'ingénierie le comportement était conforme, comme j'ai un doute je leur transférai l'élément au pire ça fera un bis repetita ou peut être c'est un autre point qui sera vu peut être non conforme comme tu l'indiques.

Cdt

UP le fil milieu de semaine pro pour pas ça passe à la trappe (merci)

[PIpou74]

Problème identique.
Serveur DHCP désactivé sur la Box mais elle répond constamment avec des DHCPNAK au request.

[ToFoo93]

Bonsoir,

PI j'ai partagé ton retour à notre ingénierie je leur ai demandé si pour eux ce n'est pas un défaut de me donner les éléments pour restituer le point soulevé.

En attendant la suite, je te remercie encore pour ton retour détaillé

Bonne soirée

[Piamp]

Bonjour,
Même problème ici : pihole derrière la bbox wifi6, qui fait aussi dhcp.
Dhcp désactivé sur la bbox.
Tout fonctionnait très bien, depuis 1 mois le pc windows 11 n'arrive pas à se connecter sauf après bcp de tentatives.
Dans les logs w11 je vois que la box envoie des dhcpnak....

[JohnKwest]

Bonjour, même problème ici: j'ai mon propre serveur DNS, depuis que j'ai remplacé le serveur DHCP de la bbox j'ai pas mal d'appareils qui ne fonctionnent tout simplement plus ou difficilement.
Étant ingénieur réseau je suis souvent confronté à des problématiques de genre, en observant les trames on voit très clairement un DHCP NAK émis par la bbox à chaque DHCPREQUEST broadcast. Et je confirme que ce comportement ne respecte ni l’esprit ni les bonnes pratiques définies par la RFC2131.

La norme indique explicitement (section 4.3.2):

"Servers that receive a DHCPREQUEST broadcast message but are not selected SHOULD NOT respond."

La justification du NAK par Bouygues est donc une mauvaise interprétation de la norme, je cite:

"le client envois le DHCP Request message en Broadcast donc le serveur de l’IAD le reçoit et il répond par un NACK."

Un serveur DHCP non concerné ne devrait jamais injecter de NAK dans un échange tiers, dans les cas évoqués la Bbox n’a aucune légitimité à envoyer un NAK. L'erreur d'interprétation est en effet flagrante et doit probablement impacter un nombre énorme d'abonnés.
Un correctif firmware serait donc hautement souhaitable.

@ToFoo93 : merci pour ton investissement sur ce forum. As-tu eu des retours techniques de Bouygues sur ce sujet ?
Peux-tu insister sur le caractère critique et largement impactant de ce bug afin qu’il soit réellement pris en compte par les équipes firmware ?