Bonjour,
Tout d'abord, merci à tous les membres qui ont partagé les résultats de leurs expériences techniques avec le réseau Orange -- cela m'a beaucoup facilité la tâche. Particulièrement, je savais à quoi m'attendre avant même de mettre un wireshark en face de la LiveBox, laquelle a dû rester moins de 24h hors de son carton :')
Au cours de mes lectures, j'ai noté que la plupart des problématiques relatives à DHCP tournaient autour du VLAN 832, de la priorité 6 (avec sa digression sur le traitement des raw sockets par le kernel), des options DHCP (60, 61, 77, 90) et de leurs valeurs. Grâce à toutes ces discussions, je n'ai pas eu de mal à faire fonctionner un client DHCPv4 sur ma passerelle et à obtenir un bail DHCPv4 avec tout ce qu'il faut (adresse, subnet, route, etc.).
Toutefois, et à moins que je n'aie loupé les posts qui en parlent, toutes les discussions se concentrent sur l'obtention initiale du bail : DISCOVER, OFFER, REQUEST, ACK.
Mais quid du renouvellement de ce bail DHCPv4 ? Est-ce que le renewal et le rebinding se passent bien chez vous ? Chez moi, ça ne se passe hélas pas très bien. Explications :
J'utilise l'ISC DHCP Client 4.3.1 tel qu'on le trouve sur Debian Jessie et je contrôle ce qu'il fait en sniffant le réseau ; tous les paquets dont je parle sortent donc taggés avec le VLAN 832, la priorité 6 et les mêmes options DHCP.
Comme déjà indiqué, l'acquisition initiale du bail se déroule bien :
Feb 22 03:12:34 dhclient: DHCPDISCOVER on <nic> to 255.255.255.255 port 67 interval 8
Feb 22 03:12:34 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 03:12:34 dhclient: DHCPOFFER from <gateway IPv4 Orange>
Feb 22 03:12:34 dhclient: DHCPACK from <gateway IPv4 Orange>
Feb 22 03:12:34 dhclient: bound to <IPv4> -- renewal in 39060 seconds.
À noter toutefois que le bail ainsi obtenu comporte une bizarrerie : les paquets DHCPOFFER et DHCPACK venaient de la gateway Orange (rien de surprenant) mais le bail stipule :
option dhcp-server-identifier 80.10.247.48;
C-à-d une IP en dehors du subnet attribué et qui ne répond pas aux pings. Bon, pourquoi pas...
Edit : après vérification, cette IP ne s'annonce pas non plus en ARP... ça promet...
Tout se passe bien jusqu'au moment du renewal, quand dhclient essaye, pour renouveler son bail, de contacter ce fameux serveur DHCP : aucune réponse en vue, que ce soit aux yeux de tcpdump ou aux yeux de dhclient :
Feb 22 14:03:34 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:03:39 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:03:46 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:04 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:22 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:43 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:04:51 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:03 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:18 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:29 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:38 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Feb 22 14:05:51 dhclient: DHCPREQUEST on <nic> to 80.10.247.48 port 67
Et ça continue comme ça pendant des heures, jusqu'au "rebinding time", où dhclient cesse de chercher à contacter le serveur DHCP via son IPv4 et se met à broadcaster sa DHCPREQUEST :
Feb 22 22:26:02 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:26:18 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:26:30 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:26:44 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:00 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:09 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:18 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:33 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:27:50 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:28:04 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:28:25 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Feb 22 22:28:44 dhclient: DHCPREQUEST on <nic> to 255.255.255.255 port 67
Et ça continue comme ça jusqu'à l'expiration du bail, qui pousse dhclient à èmettre un DHCPDISCOVER, lequel reçoit immédiatement une réponse de la gateway Orange, et la boucle peut ainsi recommencer.
Concrètement, ça n'est pas gênant : le bail est acquis aussitôt après son expiration, ce qui limite fortement les chances que l'IPv4 se voit attribuée à quelqu'un d'autre. Mais bon, émettre une DHCPREQUEST dans le vide toutes les ~15 secondes pour rien, ça pollue les logs et c'est un peu gênant sur le concept...
Mes hypothèses pour le moment :
Hypothèse 1 : le PEBKAC : j'ai loupé un épisode dans mes routes, mes règles de firewall, mes captures réseau, whatever...
Hypothèse 2 : le dhcp-server-identifier est complètement faux et le problème se résoudrait avec un hook dhclient pour remplacer le dhcp-server-identifier par la gateway IPv4. Problème : ça n'expliquerait pas pourquoi les DHCPREQUESTs broadcastées après le rebinding time ne donnent rien.
Hypothèse 3 : le serveur DHCP refuse les DHCPREQUESTs parce que, lorsqu'on a tous forcé notre option 90 (auth RFC 3118 donc) à une petite rafale de 0x00 suivie de notre login fti/xxxxxxx, on a en fait écrit ça :
# Option (90) Authentication:
# First, we have to define that option:
option authentication code 90 = string;
# Next, we set it to our login (the password remains unused), i.e. "fti/1234567",
# with 11 null bytes beforehand:
# - 1 for the authentication protocol: 0 means "configuration token"
# - 1 for the algorithm: 0 means "none"
# - 1 for RDM (Replay Detection method) type: 0 means "monotonically-increasing counter"
# - 8 for RDM (Replay Detection method) value (here, 0, simply)
send authentication 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:31:32:33:34:35:36:37;
# Note: authentication IS necessary to get a proper DHCP offer.
En clair : je soupçonne les DHCPREQUESTs de ne pas fonctionner parce que leur valeur de Replay Detection reste à 0 (idéalement, il faudrait envoyer un timestamp Unix si je ne m'abuse). Ça impliquerait toutefois qu'Orange ait implémenté de façon très scrupuleuse la RFC3118, c'est-à-dire que leurs serveurs DHCP vérifient aussi bien la valeur du token que le champ RDM.
Bref, première question pour le moment, adressée à tous ceux qui ont remplacé leur LiveBox par un équipement personnel : est-ce que ça se passe bien votre renouvellement DHCP ? Un grand merci d'avance pour vos retours.