Je n'ai toujours pas eu de réponse.
C'est clairement un bug...

Savez-vous comment signaler un BUG à Bouygtel, sans perdre du temps avec la hotline?

Leon.

Hello,

Confronté au même problème, j'avais posté un message dans le forum bbox, mais sans grand succès  : https://www.bbox-mag.fr/forum/viewtopic.php?p=23496

J'avais aussi identifié un des développeurs de l'interface web Bbox, via les commentaires dans les sources HTML / JS, que j'avais ensuite contacté via LinkedIn... mais sans aucun retour là non plus! 

A l'origine mon besoin était de pouvoir déclarer des routes sur mon réseau: c'est vraiment dommage de ne pas pouvoir le faire sur un ... routeur!
(mais bon c'est peut-être pour ça que ça s’appelle une "box" et pas un routeur  )

Bonjour kgersen,

Merci pour la réponse et pour les liens!!
Comme toi, au début je n'y croyais pas beaucoup... mais avec l'API on arrive à faire des choses

Supposons que l'on essaie de mettre en place la route suivante: 192.168.5.0/24 via 192.168.0.50
La chaine que devrait renvoyer le serveur DHCP dans l'option 121 est 18C0A805C0A80032 (représentation en hexadécimal)
Où l'on retrouve:

• 18 = 24 en décimal, la taille du masque
• C0A805 = 192.168.5, le préfixe du sous-réseau de destination
• C0A80032 = 192.168.0.50, l'adresse de la gateway

Je vous passe toutes les tentatives infructueuses , voici la syntaxe à laquelle j'arrive avec CURL:

• Tout d'abord l'authentification

curl.exe -c tmp-cookie.jar -XPOST https://mabbox.bytel.fr/api/v1/login -d password=MOT_DE_PASSE_BBOX   

• Ensuite la commande pour modifier l'option 121 (l'option est la n°2, déjà créée via l'IF web, ici je ne fais que la mettre à jour):

curl.exe -b tmp-cookie.jar -X PUT -d enable=1 -d name=121 -d value="%18%c0%a8%05%c0%a8%00%32" https://mabbox.bytel.fr/api/v1/dhcp/options/2

En bas du message, une capture de ce que l'on obtient avec Wireshark: on voit que l'option 121 est bien envoyée dans la réponse, avec la valeur 43 c0 a8 35 c0 a8 qui "ressemble assez" à ce qui a été envoyé ... mais le message a été tronqué et certains octets modifiés, ce qui le rend invalide, comme identifié en rouge par wireshark (et windows affiche un message d'erreur "Donnée non valides" suite au ipconfig /renew et ne configure pas d'adresse IP)

Il semblerait que certains octets soient reçus par l'API, stockés dans la Bbox et renvoyés dans la réponse DHCP en l'état (c0, a8, ...) alors que d'autres sont modifiés (18 --> 43, 05 --> 35, 00 --> supprimé).

En jouant avec les valeurs, pour arriver à une option valide, qui ne soit pas modifiée, j'arrive par exemple à ceci:
curl.exe -b tmp-cookie.jar -X PUT -d enable=1 -d name=121 -d value="%1b%c0%a8%20%1b%c0%a8%1b%1b" https://mabbox.bytel.fr/api/v1/dhcp/options/2
Cette commande va pousser l'option 1bc0a8201bc0a81b1b qui correspond à la règle:

• 1b = 27 en décimal, la taille du masque
• c0a8201b= 192.168.32.27, le préfixe du sous-réseau de destination
• c0a81b1b = 192.168.27.27, l'adresse de la gateway

Et là ça marche: comme on peut le voir sur la 2ème capture, Wireshark montre une trame valide et Windows obtient bien son IP et installe la route en question (même si ce n'est pas celle que je voulais au début)

Sinon, j'ai quand même envoyé un message via le formulaire de contact développeurs, car si on pouvait définir les routes directement sur la bbox, sans tout ces "bidouillages" ce serait quand même plus simple et plus propre!