Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Deux DHCP qui répondent sur le même réseau, c'est malheureusement la foire à qui répondra le plus vite.
Un routeur pour cloisonner, c'est la seule méthode propre et fiable.

La plage dhcp sur la box est une plage fourre-tout pour tout ce qui n'est pas défini en fixe mais, s'il n'y a plus de place, la box attribuera arbitrairement.
C'est pas qu'il s'en contrefout, c'est qu'il ne peut pas faire autrement dans la logique "ça doit marcher de toute façon pour le client qui fait une boulette".

En tant qu'administrateur réseau, je te répondrai que deux DHCP (ou plus) redondants sur un réseau, c'est la base si tu veux que cela fonctionne dans tous les cas. Et pour que cela fonctionne, il est nécessaire que les serveurs DHCP respectent les paramètres indiqués, et notamment les étendues et les baux statiques. Ce que tout serveur DHCP fait, tout OS confondu, sauf le Freebox server V7. Donc Bug.

C'est sûr qu'avec une conf différente ils sont très redondants.

En tant qu'admin réseau, tu dois être au courant qu'il ne faut pas attendre d'une box domestique le niveau de service attendu en entreprise. C'est le même cas de figure du pauvre (sans méchanceté) gars qui colle un switch grand public pourrave sur une infra mal protégée et fout le boxon parce qu'il croit que comme ça s'appelle "switch" ça suffit.

Pour moi ce n'est pas un bug.

Vous utilisez une entourloupe, où l'on dira une solution de contournement, pour désactiver un serveur dhcp actif....

Le DHCP Freebox cherche à attribuer une adresse mais ne trouve pas de place disponible dans le segment assigné à l'adressage.... pour ne pas faire échouer la connexion du client il préfère outrepasser les instructions autrement on pourrait tout aussi bien entendre une autre version venant de la même personne : les devs de la Freebox sont des idiots, ils n'ont pas prévu une procédure de sécurité en cas d'erreur de paramétrage.

Je suis prêt à parier que ce type de comportement fait l'objet d'un paramétrage dans le serveur DHCP, les devs de la Freebox ont choisi la solution à leurs yeux la plus "secure", prioriser la connexion du client à votre logique qui ne correspond sans doute pas au cas le plus commun.

Réfléchissons 5 minutes : je fais la même chose que vous, mais je le fais par erreur, en réalité je n'ai pas de DHCP secondaire sur le réseau.... à votre avis qu'arrive-t-il ?

La Freebox rejette toute connexion, l'utilisateur moyen est paniqué il n'arrive même plus à accéder à sa Freebox pour modifier les paramètres.
Bien sur la solution est d'assigner manuellement une adresse IP à l'ordinateur....

Bref quoi... pour moi il ne s'agit pas d'un bug il s'agit d'un choix délibéré.
Dès lors que le DHCP est activé, les dev des la Freebox présument que c'est sans doute le seul DHCP du réseau et dans un tel cas de figure ils préfèrent paramétrer le DHCP pour prioriser la connexion, afin que l'utilisateur puisse aisément retourner sur sa Freebox et modifier les paramètres de plage... c'est un choix de comportement, pas un bug

J'ai déjà fait fonctionner mon propre DHCP en lieu et place du DHCP freebox, jamais eu de soucis. Certes c'était avec la Freebox V6 mais honnêtement j'ai du mal à comprendre pourquoi ça ne marcherait pas avec le player Deviallet qui à mon avis fonctionne au niveau réseau comme n'importe quel player Free.

Interrogez-vous plutôt pourquoi votre DHCP ne fonctionnerait pas bien.

Bon, et à part deux réponses qui n'apportent rien, pas moyen d'avoir un corp FreeDev pour regarder ce bug ?
Pour info, mon DHCP fonctionnait très bien du temps de la V6. Mais visiblement il y a des paramètres supplémentaires envoyés par la FreeboxServer au player Devialet qui a du mal à faire fonctionner sa partie "Assistant Vocaux" si elle a obtenu un bail standard (IP/DNS/GW).
Avec un tel raisonnement, le Wifi devrait se rallumer tout seul, le DHCP se réactiver tout seul, etc... puisque visiblement l'utilisateur est trop idiot pour savoir ce qu'il fait.
Je ne pense pas que ce soit la volonté de Free puisque ce n'est pas le cas.
Donc pas de nouvelles pour ce bug ?
Ah ! j'avais oublié de préciser. Le problème est identique que la réponse soit en unicast ou en broadcast.

J'aime beaucoup quand ça vire dans le dédain parce que plutôt que de rien apporter ça ne va pas dans le sens décidé par l'intéressé, usant de raccourcis boiteux pour justifier son bug.

Bon ammusement, je me désabonne (oui, je sais, ça fera des vacances).

Bonjour erwan.
Ici, il n'y a pas d'autres options, tu va devoir sortir ton wireshark et recâbler ton réseau si tu veux écouter les échanges entre le Player et le Server.

Tout d'abord, en ce qui concerne ton premier bug, qui n'en est pas vraiment un, tu peux assigner la plage x.x.x.253-254 le routeur utilisant l'ip 254, une seule ip peux donc être attribuée.
Et dans ton cas le plus simple serais de désactiver le dhcp du serveur si tu ne veux pas t'en servir après avoir récupéré les paramètres du Player (via wireshark).

Enfin pour ton deuxième bug, qui n'en est pas vraiment un non plus, quelques explications supplémentaires sont nécessaires pour bien comprendre pourquoi c'est normal.
Comme "lat" l'a remarqué, quand plusieurs serveurs DHCP sont en concurrence sur le même réseau, le premier qui répond va traiter la requête.
Ou quand ceux ci ont les même paramètres, il n'y a aucun problème tout en effectuant une fonction de redondance comme tu a pu le signaler.
Un problème commun, toutefois, comme dans ton cas précis ou chacun des serveur possède une plage spécifique, ils se doivent de cohabiter toute en se gênant le moins possible.
Tu peux te douter que quelqu'un s'étais déjà posé la question et pour cela le protocole DHCP prévois qu'un client puisse demander une adresse qui lui a déjà été attribuée.
Evidemment ton serveur freebox reçois la requête en premier, vois qu'il n'y a pas d'ip disponible dans la plage et se met a pleurer, que nenni lui répond le client qui précise qu'il avais déjà une ip avant!
Mais la c'est le drame, que faire devant un tel dilemme ? Heureusement dans sa grande bienveillance, le protocole DHCP avait tout prévu.
"Oui! Tu ne laissera point de clients sans IP", c'est ainsi que les dieux du réseau (et non ce n'était pas les devs de la freebox) avaient réglé ce problème en comité.
Ici, le serveur a retrouvé immédiatement le sourire, attribue l'ip demandée par le client, sans se poser de questions, et tout le monde repart content d'avoir trouvé un accord. N'est ce pas fabuleux ?

Bon, les enfants, il est grand temps d'aller au lit. Vous en profiterez pour lire vos cours de réseaux, vu que visiblement ce n'est pas compris.

<TLDR> A la différence de certains, quand j'ai un doute, je vérifie mes connaissances, même si ça fait 25 ans que ça n'a pas évolué.
Donc La lecture du manuel de DHCPD (ou du manuel Microsoft, au choix), la RFC2131, ainsi que la capture montre très exactement qu'un serveur DHCP ne répond qu'en fournissant une IP dans un scope pour lequel il est autorisé à répondre, et qu'en l'absence de possibilité, il s'abstient.
</TLDR>

Vous êtes encore là ? alors on y va:
1) s'il y a plusieurs DHCP sur le réseau, chacun répond à la demande du client. Et c'est le CLIENT et non le serveur qui CHOISIT parmi les possibilités. Il INDIQUE alors qu'il accepte ou refuse. Le seul cas de REFUS par un serveur, c'est lorsque le client demande une certaine IP, que le serveur est RESPONSABLE de cette IP, et qu'il sait qu'elle a été attribuée entre temps ou est déjà utilisée.

2) La page du manuel de DHCPD est extrêmement claire:
When the DHCP server allocates a new address for a client (remember, this only happens if the client has sent a DHCPDISCOVER), it first looks to see if the client already has a valid lease on an IP address, or if there is an old IP address the client had before that hasn't yet been reassigned. In that case, the server will take that address and check it to see if the client is still permitted to use it. If the client is no longer permitted to use it, the lease is freed if the server thought it was still in use - the fact that the client has sent a DHCPDISCOVER proves to the server that the client is no longer using the lease. If no existing lease is found, or if the client is forbidden to receive the existing lease, then the server will look in the list of address pools for the network segment to which the client is attached for a lease that is not in use and that the client is permitted to have. It looks through each pool declaration in sequence (all range declarations that appear outside of pool declarations are grouped into a single pool with no permit list). If the permit list for the pool allows the client to be allocated an address from that pool, the pool is examined to see if there is an address available. If so, then the client is tentatively assigned that address. Otherwise, the next pool is tested. If no addresses are found that can be assigned to the client, no response is sent to the client. If an address is found that the client is permitted to have, and that has never been assigned to any client before, the address is immediately allocated to the client. If the address is available for allocation but has been previously assigned to a different client, the server will keep looking in hopes of finding an address that has never before been assigned to a client.
ce que l'on trouve aussi dans la RFC, section 3.2:

If the client's request is invalid (e.g., the client has moved
to a new subnet), servers SHOULD respond with a DHCPNAK message to
the client. Servers SHOULD NOT respond if their information is not
guaranteed to be accurate. For example, a server that identifies a
request for an expired binding that is owned by another server SHOULD
NOT respond with a DHCPNAK unless the servers are using an explicit
mechanism to maintain coherency among the servers.

Donc non, un serveur DHCP peut tout à fait laisser un client sans IP. S'il n'y a plus de place et dans AUCUN cas il ne va AUTORISER un bail DHCP sur un Scope sur lequel il n'a pas autorité.

Et dans la vraie vie, ça donne quoi ?

On se fait un petit proof of concept, deux serveurs DHCP sur le LAN 192.168.42.0/24, le premier en .1, le second en .2. On les parametres à l'ancienne, sans failover, avec la regle des 80-20 sur 192.168.42.100-199. Le premier a donc le scope 192.168.42.100-179, et le second 192.168.42.180-199. Et on introduit un client DHCP.

Le client recoit les deux réponse, il choisit le serveur 1, et celui-ci accepte.

Le serveur a maintenant un bail, et on éteint le serveur DHCP1 puis on redémarre le client.

Le client essaye de renouveler son bail auprès de DHCP1, qui ne peut pas répondre. En time out, il recommence toute la procédure, et DHCP2 répond.
Il lui offre une IP DANS SA PLAGE, ce qu'accepte le client.

On repart pour un tour, avec DHCP1 qui a fourni le bail, mais si DHCP2 est bien actif, on lui a défini des réservations sur toute sa plage. Il n'a donc PAS d'adresses ip disponible dans son scope.
et ...

Il reste seul, sans IP. DHCP2 NE REPOND PAS. Il n'a pas le droit de le faire.

Erwan, tout d'abord permet moi de te féliciter pour ton travail, cette démonstration de ta capacité à configurer non pas un mais deux serveur DHCP afin de ne renvoyer aucune adresse est superbe.
Je vois aussi avec plaisir que tu as même recopié l'extrait de la documentation de dhcpd qui concerne ta question.
Toutefois je suis obligé de constater que ton analyse de la situation est erronée.
Avant tout, revoyons la scène au ralenti !
Ici, tu considère que ton test démontre le comportement attendu de la part d'un serveur DHCP correctement configuré, libre à toi.
Mais l'erreur vient du fait que l'équivalence est impossible, de fait, tu ne contrôle que partiellement le serveur DHCP de la freebox, c'est donc à toi de t'adapter, ou de te passer de celui-ci.
Et au final, tu semble continuer à penser que cette situation est une anomalie, alors que ce n'est qu'une question de configuration qui ne te plait pas et que tu avais trouvé pourquoi.
La crucifixion n'étant plus d'usage, une simple démonstration suffira.

Dans la documentation que tu a citée ci-dessus, on peux y lire :
"It first looks to see if the client already has a valid lease on an IP address, or if there is an old IP address the client had before that hasn't yet been reassigned. In that case, the server will take that address and check it to see if the client is still permitted to use it".
Bonus wikipedia : "A DHCP client may also request its last known IP address. If the client remains connected to the same network, the server may grant the request.".
Et voila ! Pas besoin d'aller plus loin tout est dit.

Comme tu peux t'en douter, à la question:
"check it to see if the client is still permitted to use it"
Le serveur DHCP de la freebox répond oui, dans ta démonstration le serveur répond non.

Pour ma part je te propose encore une fois de désactiver le serveur DHCP de la Freebox, si ce n'est pas le comportement que tu souhaite observer sur ton réseau local.

Cher Omin Oreg.

Quand tu seras grand, tu comprendras qu'une interface qui te permet de saisir des paramètres qui ne seront pas respectés, on appelle cela un bug. Et une implémentation qui ne respecte pas la RFC, c'est aussi un bug.
Full Disclosure: je suis assez vieux pour avoir travaillé sur les premiers serveurs DHCP . Je crois donc maîtriser le sujet, et me rendre compte des nombreuses factuelles de tes réponses.

On va donc faire simple, parce que je n'ai pas le temps de corriger toute ta copie: tu es incapable de lire une documentation, ou même de comprendre un RFC. Laisse ça au grands et retourne ranger ta chambre. Tu y trouveras peut être un cours sur le réseau que tu as oublié de lire. Ce serait bien que tu le fasses la prochaine fois avant avant de répondre.

Erwan, quand t'auras fini de faire de l'ad hominem pour masquer ta mauvaise foi crasse, tu nous appelles ?

Erwan,
Je comprends ta frustration, mais encore une fois tu te trompe.
Ce n'est pas un bug, c'est un choix volontaire de configuration d'un FAI qui ne souhaite pas recevoir d'appels de Mme machin toutes les cinq minute parce que son petit fils n'arrive pas à jouer en ligne avec sa console après avoir bricolé la freeteuse.
Donc oui le RFC c'est bien mais il est bien souvent nécessaire de savoir faire preuve de souplesse dans son implémentation pour satisfaire tout le monde.

Je peux comprendre que ce choix ne te plaise pas, toutefois si tu veux vraiment savoir pourquoi cette configuration est possible, pourquoi ce n'est pas une erreur d'implémentation et pourquoi des millions d'utilisateurs utilisent quotidiennement des serveurs DHCP configurés ainsi (sacrilège!), et comment une seule lettre a changé le monde du DHCP à jamais!!
Je te propose de poser directement la question au pourfendeur de RFC à Simon. Il est bien plus compétent que moi en la matière et de plus il est très sympathique, bien que ces temps-ci il passe plus de temps dans son jardin que devant son clavier.
Tu peux le contacter à l'adresse suivante : simon@thekelleys.org.uk
Par contre, je préfère te prévenir d'avance, sa réponse risque de ne pas te plaire.

Pour ce qui est des développeurs de la freebox, je pense avoir exposé leur choix ci-dessus, mais malheureusement pour toi, je doute qu'ils daignent perdre leur temps à te répondre.
Entre les (vrais) bugs de la delta et le module 4g avec antenne externe, ils ont déjà fort à faire ces temps-ci.

Erwan, si il n'y avait qu'une leçon à retenir, ne serait ce pas qu'étant donné tes compétences tu aurais pu configurer ta Freebox en mode bridge, gérer ton propre routeur comme tu l'entends et te passer ainsi de toutes ces tracasseries inutiles ?
Je vois bien que mon excès de vulgarisation à provoqué chez toi une réaction d'agacement spontané, mais tu dois comprendre que je ne cherchais pas à t'égarer mais à te guider vers une phase d'acceptation nécessaire désormais, ce n'est pas un bug.