default mise meme quand ce n'est pas desirer #43

New issue

Closed

opened 2026-08-23 19:52:48 +00:00 by nicolas.boufideline · 1 comment

nicolas.boufideline commented

2026-08-23 19:52:48 +00:00

Owner

Actuellement une default est mise par dnsmasq même quand on en veut pas.
la solution c'est de mettre, dhcp-option=3 vide, sinon il prend une ip bien precise...

Actuellement une default est mise par dnsmasq même quand on en veut pas. la solution c'est de mettre, dhcp-option=3 vide, sinon il prend une ip bien precise...

nicolas.boufideline added the

bug fix

label

2026-08-23 19:52:59 +00:00

nicolas.boufideline added this to the 0.1.0 milestone

2026-08-23 19:53:01 +00:00

nicolas.boufideline referenced this issue from a commit

2026-08-24 19:20:14 +00:00

f-43: dhcp: fix default route create for nothing #43

nicolas.boufideline referenced this issue from a commit

2026-08-24 19:20:14 +00:00

f-43: test: fix default route create for nothing #43

nicolas.boufideline closed this issue

2026-08-24 19:38:14 +00:00

nicolas.boufideline commented

2026-08-25 12:39:18 +00:00

Author

Owner

Corrigé le 2026-08-24, validé sur lab3.

Cause racine — internal/dhcp/generate.go n'émettait dhcp-option=3 que si une gateway était connue. Sans directive, dnsmasq applique son défaut et s'annonce lui-même comme routeur : ne rien écrire n'était pas « ne rien envoyer », mais « envoyer le défaut ». Man dnsmasq : « Options for which dnsmasq normally provides default values can be omitted by defining the option with no data. »

Correctif — émission de l'option nue dhcp-option=3, qui supprime réellement le routeur. Portée plus large que prévu : tout subnet vxlan était concerné, alors qu'un vxlan est privé par construction.

Piège associé — le test qui existait vérifiait l'absence de la ligne dans le fichier, donc l'état du fichier et non le comportement obtenu. Il était vert pendant que le bug était là.

Ce correctif a introduit une régression, corrigée le jour même : en supprimant la route par défaut, il a supprimé le seul chemin des guests vers 169.254.169.254, donc vers le serveur de métadonnées — cloud-init ne trouvait plus son datasource. La route est désormais annoncée explicitement en option 121.

Depuis, la décision a été revue (cf. #31) : une route par défaut est de nouveau toujours annoncée, mais vers un next-hop choisi (interface_ip par défaut) au lieu d'être fabriquée par dnsmasq. Le ticket reste fermé : c'est ce correctif qui a rendu ce next-hop contrôlable.

Corrigé le 2026-08-24, validé sur lab3. **Cause racine** — `internal/dhcp/generate.go` n'émettait `dhcp-option=3` que si une gateway était connue. Sans directive, dnsmasq **applique son défaut** et s'annonce lui-même comme routeur : ne rien écrire n'était pas « ne rien envoyer », mais « envoyer le défaut ». Man dnsmasq : *« Options for which dnsmasq normally provides default values can be omitted by defining the option with no data. »* **Correctif** — émission de l'option **nue** `dhcp-option=3`, qui supprime réellement le routeur. Portée plus large que prévu : tout subnet vxlan était concerné, alors qu'un vxlan est privé par construction. **Piège associé** — le test qui existait vérifiait l'absence de la ligne dans le fichier, donc l'état du fichier et non le comportement obtenu. Il était vert pendant que le bug était là. **Ce correctif a introduit une régression**, corrigée le jour même : en supprimant la route par défaut, il a supprimé le seul chemin des guests vers `169.254.169.254`, donc vers le serveur de métadonnées — cloud-init ne trouvait plus son datasource. La route est désormais annoncée explicitement en option 121. **Depuis, la décision a été revue** (cf. #31) : une route par défaut est de nouveau **toujours** annoncée, mais vers un next-hop choisi (`interface_ip` par défaut) au lieu d'être fabriquée par dnsmasq. Le ticket reste fermé : c'est ce correctif qui a rendu ce next-hop contrôlable.

nicolas.boufideline referenced this issue

2026-08-25 12:39:19 +00:00

Gestion avancer des subnet #28