Hello,

Tout d'abord, merci à tous pour ces informations qui m'ont permis de rapidement rétablir ma connexion

Petit pinaillage technique cela dit :

• D'abord, il y a cette séquence d'octets définie en dur dans le binaire, je ne sais pas à quoi elle correspond : 1a0900000558010341 (1a est donc le type et 09 la taille)
• Ensuite, un autre champ fixe dont la valeur est "A", peut-être une version de format... : 010341 (01 est le type, 03 est la taille, 41 est la valeur "A" en ASCII)

Cet "autre champ fixe dont la valeur est A" n'existe pas... ce 010341 fait partie de la valeur du champ précédent 1a0900000558010341 -- je crois que tu t'es emmêlé les pinceaux.

Mon authentification DHCP avec la chaîne courte (juste le "fti/xxx") a arrêté de fonctionner samedi 28 septembre à 8h10. J'ai généré une chaîne longue à partir de mon mot de passe, d'une chaine aléatoire de 16 octets et du hash MD5 et j'ai réussi à me connecter du premier coup en IPv4 et IPv6 depuis mon routeur Turris Omnia !

Bon, ben j'y ai eu droit ce ce matin, ce qui m'a valu un déplacement sur site. heureusement, j'avais mis la nouvelle conf préparée en commentaire...

Par contre, chez moi, la chaîne complète n'a PAS marché, j'ai dû remplacer

     option sendopts '0x4d:2b...33 0x5a:0000000000000000000000xxxxxxxxxxxxxxxxxxxxxx'

par

     option sendopts '0x4d:2b...33 0x5a:00000000000000000000001a0900000558010341010dxxxxxxxxxxxxxxxxxxxxxx'  .

Ca a marché sur le DGA4130.



La chaine complète avait été crée ainsi : (Je vous rassure j'ai changé login & mot de passe & mac ci-dessous )

#  Option 77 (0x4D) : 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 (valeur fixe ?)

#  Option 90 (0x5A) : Suite de champs <type><taille><data> , la taille incluant les data + les 2 octets de type et taille:   
#    0000000000000000000000 (valeur fixe) + 1a0900000558010341 (valeur fixe)  +                                                                                                               
#    010d + (username ppp avec  le fti/ sur 11 caracteres)  +                                                                                                                                 
#    3c12XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (ou les XX sont 16 octets aléatoire <RANDSTRING>) +                               
#    0313YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY (ou les YY sont une valeur calculée ainsi :  1 octet aléatoire <RANDCHAR>                                                                         
#                                           + hash MD5 de (RANDCHAR + PASSWORD + RANDSTRING), PASSWORD étant le pass ppp)                                                                   
#  Option 61 (0x3D) :01ZZZZZZZZZZZZ' ou les ZZ sont l'adresse MAC de la box.                                                                                                               
                                                                                                                                                                                             
#   username PPP  = fti/2222222
#   password PPP   = aaaaaaa
#                mac      = 58:92:44:E9:A0:22
#
#  Ce qui donne : (avec RANDCHAR = 'e' et RANDSTRING = 'f5y6n8e8u9spe8p9')
#                                                                                                                                                                                             

option sendopts '0x4d:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833 \
0x5d:0x5a:00000000000000000000001a0900000558010341010d6674692f323232323232323c12663579366e386538753973706538703903136565 64373833663538373832666461316139393731386661323331663435353362\
0x3d:01589244e9a022

Et.... échec total , pas d'IP.

Pour calculer la valeur à placer dans 0313 , j'ai fait ainsi :
J'ai créé un fichier avec le contenu "eaaaaaaaf5y6n8e8u9spe8p9" (sans le 0x0a à la fin), puis :
     md5sum <fichier> | hexdump -C
Et j'ai pris les valeurs en hexa.

Ce que je comprends pas c'est que le préfixe 0313 implique d'avoir 17 octets : Le randchar + 16 octets de MD5 . Mais chez moi md5sum me donne 32 octets, pas 16...


Dans l'urgence j'ai remis la conf qui marchait (15 personnes étaient coupées , quand même) mais je compte me re-pencher sur la question et , pourquoi pas, faire un petit script qui calcule & affiche les valeurs.

Un hash MD5 c'est 128 bits soit 16 bytes de 8 bits (un octet donc). Pour représenter un octet, il faut deux caractères hexa (0-9a-f); md5sum te donne 32 octets car il te donne 32 caractères hexa pour représenter ces 16 octets de données.

OK , donc j'ai fait de la merde :-) D'un coté ça rassure.

Mais ca veux dire au moins qu'Orange valide un minimum les champs.

Donc là, on a pas de réponse DHCP si on met pas le bon passwd, mais on en a une si on en met pas ? (ou j’ai raté un truc ?)

Le mot de passe (champs salt 0x3c et hash 0x03) n'est pour le moment pas vérifié. Mais envoyer des champs avec des données non cohérentes (par exemple plus ou moins de données que ne l'indique la taille d'un champ) est généralement un bon moyen de voir ses requêtes DHCP purement et simplement ignorées.

j'ai fait un générateur a la vite : https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/

C'est surement pas au point et je ne suis plus chez Orange pour tester. n’hésitez pas a le corriger et repartager.

Ma contribution en bash avec un minimum de dépendances (dd+ md5sum + sed + cut), basé sur le script de @bob62 sur le tuto pour dd-wrt (mais je ne suis pas d'accord avec son implèmentation ). Pas testé mais ça devrait être bon...

#!/bin/bash

login='fti/abcdefg'
pass='hijklmn'

tohex() {
  for h in $(echo $1 | sed "s/\(.\)/\1 /g"); do printf %02x \'$h; done
}

addsep() {
  echo $(echo $1 | sed "s/\(.\)\(.\)/:\1\2/g")
}

r=$(dd if=/dev/urandom bs=1k count=1 2>&1 | md5sum | cut -c1-16)
id=${r:0:1}
h=3C12$(tohex ${r})0313$(tohex ${id})$(echo -n ${id}${pass}${r} | md5sum | cut -c1-32)

echo 00:00:00:00:00:00:00:00:00:00:00:1A:09:00:00:05:58:01:03:41:01:0D$(addsep $(tohex ${login})${h})