La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: Mastah le 26 septembre 2018 à 21:22:52
-
Comme vous le savez, orange à modifié la manière dont l'authentification DHCP est réalisé.
Ancienne échange hexa DHCP (option 90)
00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Nouvel échange hexa DHCP (option 90)
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh
Je vous propose donc de mettre en commun nos cerveaux et de chercher quelle pourrait être la manière de génération des deux parties qui sont ajouté avant et après l'identifiant.
Edit:
Le pattern qui semble fonctionner
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Info disponible
Salut les loulous.
Il se trouve que j'avais reversé la partie concernée du firmware Livebox 3 qui génère cette option DHCP, je vais donc vous faire part de mes notes.
- Les 11 premiers octets sont mis à 0 : il s'agit d'un emplacement de la taille de l'en-tête de l'option 90 DHCP standard, telle que définie dans la RFC 3118 (https://tools.ietf.org/html/rfc3118). Ces paramètres n'étant pas utilisés, ils sont mis à 0.
- Ensuite, il s'agit d'une séquence de champs TLV (type-length-value). Autrement dit, il s'agit d'une séquence de paramètres propriétaires définis par Orange qui suivent ce motif : 1 octet de type, 1 octet de taille (comprenant les octets de type, de taille et de valeur), suivi d'un certain nombre d'octets de valeur en fonction de la taille.
- 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)
- Ensuite, un champ dont le type est étrangement aussi 01, et la valeur est l'identifiant PPP Orange (appelons-le USERNAME), je ne vous fais pas de dessin : 010dXXXXXXXXXXXXXXXXXXXXXX
- Ensuite, un champ dont le type est 3c, qui contient 16 octets aléatoires (appelons-les RANDSTRING) est généré par le client DHCP si je me souviens bien : 3c12XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- Enfin, un champ dont le type est 03, et qui contient 17 octets de valeur :
- 1 octet aléatoire, appelons-le RANDCHAR, immédiatement suivi de
- 16 octets qui sont un hash MD5 généré avec la formule suivante : MD5(RANDCHAR + PASSWORD + RANDSTRING), où PASSWORD est le mot de passe PPP
Voilà pour mes notes les kidz ! Amusez-vous bien
Le xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx correspond à la chaine fti/xxxxx orange
-
Pour moi cela remarche après sniffing sur le port WAN de l'option 90 et 11 (IPv6), après remis dans le Mikrotik avec "0x22_zeros_avant_le_nouveau_code_hexa".
-
Alors 2 infos:
- La partie avant le fti est fixe (identique pour tout le monde) Edit: Si j'ai bien compris le post de @Aize147, si on met tout à 00 ça marche quand même
- La partie après le fti change à chaque renew.... mais ils semble que pour l'instant on peut obtenir une IP même si on réutilise plusieurs fois la même
Je vais essayer de capturer ce que fait la box sur plusieurs jours afin d'avoir plusieurs échantillons de la partie variable...
Du coup, question: Est-ce que par hasard ça ne marcherait pas avec simplement 22 fois 00 + le fti/xxxxx sans tout le bordel pseudo random qui suit ?
-
Je teste sans tout le bordel derrière.
-
C'est ok avec
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
-
Lol, tout ça pour ça, franchement ;D
Quoi qu'il en soit, étant donné que actuellement ma Livebox est client DHCP de mon routeur, je crois qu'elle va devenir mon générateur officiel de code d'auhentification, au cas où un jour la partie "random" devient obligatoire et doit changer régulièrement...
-
regardez la norme pour l'option 90, https://tools.ietf.org/html/rfc3118. Orange s'est peut-etre mis a jour pour être rentrer dans la norme (ce qui n'était pas le cas avant) ? (on parle de rumeur de routeurs du commerce qui seraient bientot compatibles avec les connexions Orange).
le truc qui change a chaque renew ca serait pas le Replay Detection de la norme ?
-
OK
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KO
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
-
le truc qui change a chaque renew ca serait pas le Replay Detection de la norme ?
Non, le replay detection devrait être avant le fti si j'ai bien compris la RFC (à la place des 00).
-
regardez la norme pour l'option 90, https://tools.ietf.org/html/rfc3118. Orange s'est peut-etre mis a jour pour être rentrer dans la norme (ce qui n'était pas le cas avant) ? (on parle de rumeur de routeurs du commerce qui seraient bientot compatibles avec les connexions Orange).
le truc qui change a chaque renew ca serait pas le Replay Detection de la norme ?
C'est possible... Je ne suis pas assez calé en DHCP cela dit ^^
Par contre, si ce que tu dis est vrai, c'est une très bonne nouvelle pour l'ouverture avec un remplacement de la box orange par autre chose !
-
Salut les loulous.
Il se trouve que j'avais reversé la partie concernée du firmware Livebox 3 qui génère cette option DHCP, je vais donc vous faire part de mes notes.
- Les 11 premiers octets sont mis à 0 : il s'agit d'un emplacement de la taille de l'en-tête de l'option 90 DHCP standard, telle que définie dans la RFC 3118 (https://tools.ietf.org/html/rfc3118). Ces paramètres n'étant pas utilisés, ils sont mis à 0.
- Ensuite, il s'agit d'une séquence de champs TLV (type-length-value). Autrement dit, il s'agit d'une séquence de paramètres propriétaires définis par Orange qui suivent ce motif : 1 octet de type, 1 octet de taille (comprenant les octets de type, de taille et de valeur), suivi d'un certain nombre d'octets de valeur en fonction de la taille.
- 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)
- Ensuite, un champ dont le type est étrangement aussi 01, et la valeur est l'identifiant PPP Orange (appelons-le USERNAME), je ne vous fais pas de dessin : 010dXXXXXXXXXXXXXXXXXXXXXX
- Ensuite, un champ dont le type est 3c, qui contient 16 octets aléatoires (appelons-les RANDSTRING) est généré par le client DHCP si je me souviens bien : 3c12XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- Enfin, un champ dont le type est 03, et qui contient 17 octets de valeur :
- 1 octet aléatoire, appelons-le RANDCHAR, immédiatement suivi de
- 16 octets qui sont un hash MD5 généré avec la formule suivante : MD5(RANDCHAR + PASSWORD + RANDSTRING), où PASSWORD est le mot de passe PPP
Voilà pour mes notes les kidz ! Amusez-vous bien
-
Thanks !
-
Voilà pour mes notes les kidz ! Amusez-vous bien
La vache, merci beaucoup dad ;D
Donc grosso modo, de la data random qui fait office de seed pour hacher le password. Conclusion, en utilisant une chaine issue d'un sniff on devrait pouvoir s'authentifier et la chaine ne devrait pas expirer (m'étonnerait qu'Orange conserve pour chaque client une liste de seeds pour éviter le rejeu).
-
Du coup, toute la partie non obligatoire à la fin de la chaine, on risque un truc à la laisser ?
-
Du coup, toute la partie non obligatoire à la fin de la chaine, on risque un truc à la laisser ?
Oui, pour ma part toute la partie hexa après le "fti/xxxxx" ne sert pas.
-
Du coup, toute la partie non obligatoire à la fin de la chaine, on risque un truc à la laisser ?
livebox l'envoie. Donc, nous devrions aussi
-
OK
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
KO
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
salut
pareil ici, je viens de tester sur mon EdgeRoute Lite
- ancienne formule avec 11x00 + fti : ca marche
- nouvelle formule avec 11x00 + 1a:09:00:00:05:58:01:03:41:01:0d + fti : ca marche
- nouvelle formule avec 22x00 + fti : marche pas, FAIL en retour
pour ce qui est des trucs randoms après... à voir j'espere que ca ne sera pas trop aléatoire et dur à trouver/renouveler.
(et chez moi j'ai besoin de la prio 6 pour les requetes dhcp)
merci de l'info en tout cas :)
-
livebox l'envoie. Donc, nous devrions aussi
Je suis d'accord avec ça. Elle contient le mot de passe du client. Si Orange l'a mis là, c'est pour à un moment donné valider qu'il est bon...
-
Ok, bon, j'envoi tout alors. Merci.
-
Je suis d'accord avec ça. Elle contient le mot de passe du client. Si Orange l'a mis là, c'est pour à un moment donné valider qu'il est bon...
Tu lève une bonne piste. Le mot de passe du client hashé ? Qu'en pensez vous ?
PS : moi mon mot de passe à disparu de l'interface de gestion Orange, je l'ai retrouvé dans un vieux SMS de Orange
-
Ici avec un dibbler 1.0.1 je vois « AUTH: protocol xxxxx not supported yet. », xxxxx étant un chiffre qui change à chaque fois que je relance le client.
2018.09.27 10:26:10 Client Info Processing msg (SOLICIT,transID=0x11b8ff,opts: 1 25 8 16 15 11 11 90 6)
2018.09.27 10:26:10 Client Error AUTH: protocol 21968 not supported yet.
J’avais suivi https://lafibre.info/remplacer-livebox/remplacer-la-livebox-sans-pppoe/ et j’ai ajouté « option 90 hex 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:fti-en-hexa » à la suite des autres options. Je n’utilisais pas l’option 90 avant.
J’ai déjà appliqué la QoS avec iptables et ip6tables.
Pour le moment la v4 fonctionne toujours, mais il est possible que mon bail ne soit pas encore expiré.
Quelqu’un d’autre est dans cette situation ?
-
Il n'y a toujours pas besoin d'option 90 avec dibbler, seule l'option 11 est à ajuster en conséquence.
-
Merci pour l'info, Suite a un reboot a distance, hier matin je ne pouvais plus avoir d'IP je pensais avori fait un connerie jusqu'a ce que je tombe sur le topic hier soir ::) ;D
J'ai pas pensé à faire une capture coté box vu que c'était suite a modif de ma conf :(
je test tout ça en rentrant
-
Effectivement, c’est remonté en modifiant l’option 11 en v6 (et pas l’option 90 utilisée en v4).
Merci beaucoup :)
Je suis bien content d’avoir une ADSL à Grifon à côté moi :D
-
Est-ce que ce serait possible de corriger le titre, de Cacking à Cracking ?
-
Est-ce que ce serait possible de corriger le titre, de Cacking à Cracking ?
Je pense pas qu'on est le droit de parler de c*acking, d'ou la faute de frappe ;)
-
Bah si, on a le droit de reverse engineering pour comptabilité d'emploi, comme ce qu'a fait l'équipe samba pour être compatible avec le protocole SMB de Microsoft.
-
Reverse engineering != Cracking, enfin ça n'engage que moi
-
Bah si, on a le droit de reverse engineering pour comptabilité d'emploi,
Source ?
-
Article L122-6-1 du code de la propriété intellectuelle :
De nombreux éditeurs de logiciels propriétaires incluent dans leurs CLUF des clauses interdisant la rétro-ingénierie. Cependant dans de nombreux pays la rétro-ingénierie est autorisée par la loi, notamment à des fins d'interopérabilité. Dans ces pays, les clauses de ces CLUF ne sont pas valables, ou tout au plus dans les limites déterminées par la loi.
Par exemple en France, ce droit est garanti par l'article L122-6-1 du code de la propriété intellectuelle7. On trouve des dispositions similaires dans la directive 2009/24/CE du Parlement européen et du Conseil du 23 avril 20098.
https://fr.wikipedia.org/wiki/R%C3%A9tro-ing%C3%A9nierie
Citation de cet article :
IV. La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes :
1° Ces actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin ;
2° Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au 1° ci-dessus ;
3° Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité.
https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006069414&idArticle=LEGIARTI000006278920&dateTexte=&categorieLien=cid
-
Salut les loulous.
Il se trouve que j'avais reversé la partie concernée du firmware Livebox 3 qui génère cette option DHCP, je vais donc vous faire part de mes notes.
- Les 11 premiers octets sont mis à 0 : il s'agit d'un emplacement de la taille de l'en-tête de l'option 90 DHCP standard, telle que définie dans la RFC 3118 (https://tools.ietf.org/html/rfc3118). Ces paramètres n'étant pas utilisés, ils sont mis à 0.
- Ensuite, il s'agit d'une séquence de champs TLV (type-length-value). Autrement dit, il s'agit d'une séquence de paramètres propriétaires définis par Orange qui suivent ce motif : 1 octet de type, 1 octet de taille (comprenant les octets de type, de taille et de valeur), suivi d'un certain nombre d'octets de valeur en fonction de la taille.
- 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)
- Ensuite, un champ dont le type est étrangement aussi 01, et la valeur est l'identifiant PPP Orange (appelons-le USERNAME), je ne vous fais pas de dessin : 010dXXXXXXXXXXXXXXXXXXXXXX
- Ensuite, un champ dont le type est 3c, qui contient 16 octets aléatoires (appelons-les RANDSTRING) est généré par le client DHCP si je me souviens bien : 3c12XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
- Enfin, un champ dont le type est 03, et qui contient 17 octets de valeur :
- 1 octet aléatoire, appelons-le RANDCHAR, immédiatement suivi de
- 16 octets qui sont un hash MD5 généré avec la formule suivante : MD5(RANDCHAR + PASSWORD + RANDSTRING), où PASSWORD est le mot de passe PPP
Voilà pour mes notes les kidz ! Amusez-vous bien
Ça serait pas de l'authentification par challenge-response des fois ?
-
Ca ressemble à du CHAP effectivement, sauf que dans le vrai CHAP c'est le serveur qui génère le challenge, contrairement à ici.
Mais en même temps, difficile de faire du vrai CHAP au dessus de DHCP...
-
Reverse engineering != Cracking, enfin ça n'engage que moi
Oui, tout à fait. Donc le sujet pourrait être renommé en 'Reverse Engeneering' plutôt que Cacking qui ne veut rien dire (ou plutôt suggère fortement une activité illégale).
-
Quoi qu'il en soit, je pense que le post de Gucci gang a bien tout résumé (sauf les petits points d'ombre restants qui semblent secondaires), donc il n'y a plus vraiment grand chose à "cracker"...
Reste que maintenant si Orange a décidé de faire une sorte de CHAP au dessus de DHCP, ils vont potentiellement pouvoir détecter le rejeu (challenges identiques, contrairement à la Livebox où ça change toute le temps) et le bloquer. Seule solution contre ça: Un client DHCP patché qui génère un challenge aléatoire différent à chaque fois.
-
En 2040 ils proposeront l'option de bridge comme beaucoup d'autres déjà ou un DHCP direct... c'est beau de rêver :'(
-
Reverse engineering != Cracking, enfin ça n'engage que moi
Édition du titre fait.
-
En 2040 ils proposeront l'option de bridge comme beaucoup d'autres déjà ou un DHCP direct... c'est beau de rêver :'(
Le pire c'est que c'est exactement ça: Si la Livebox avait un mode bridge, elle serait devant mon routeur et je ne chercherais même pas à m'en passer...
-
Moi j'aimerais bien faire une sorte de bridge maison, et que l'IP soit attribuée a un équipement en DHCP classique, sans avoir faire des modifs des fichiers de conf.
Genre on aurait --fibre --> [TPLinkMC220] -->[équipement gérant le DHCP - patché]---->[FW qui reçoit l'IP publique en dhcp "legacy"] façon Freebox quoi.
-
Moi j'aimerais bien faire une sorte de bridge maison, et que l'IP soit attribuée a un équipement en DHCP classique, sans avoir faire des modifs des fichiers de conf.
Genre on aurait --fibre --> [TPLinkMC220] -->[équipement gérant le DHCP - patché]---->[FW qui reçoit l'IP publique en dhcp "legacy"] façon Freebox quoi.
Ce que permet opnsense ? tu peux avoir l'IPv4 et l'IPv6 sans modification de binaire ou quoi que ce soit
-
ouais pas faut, avec un NAT 1:1, mais ça implique d'avoir 2 NAT consécutif, Je pensais au appliance FW Netasq, Stormshield, Fortinet, routeur genre Synology and co donc avoir l'IP publique directement sur cette équipement et non un autre en amont
Tout équipement dont les gens aiment l'érgo mais qu'ils ne peuvent pas utiliser car fichier de conf difficilement modifiable
-
Je ne vois pas vraiment comment ça pourrait être possible : il faudrait qu'à la fois l'équipement gérant le client dhcp et le fw aient l'ip en question. Alors certes, dhclient et autres utilisent généralement du raw socket, donc ça devrait pouvoir fonctionner, mais ça reste un hack sale.
L'autre solution que je vois est de faire un firewall transparent, sur un bridge, et donc sans ip (et sans routage donc) dessus. C'est plus propre...
-
Bonjour
J'ai récemment update mon pfense à la version 2.4.4 cela à marcher à peine deux jours avec ipv4 et dhcp
puis depuis hier plus rien le renew dhcp ne marche plus j'ai essayé vos chaines pour l'option 90
de plus j'ai l'impression que l'option de prio dhcp ne marche pas quelqu'un fait des tests la nouvelle version de pfsense
si vous voulez j'ai utilisé l'outil liveboxbox info et j'ai fait un snif sur le port wan ma livebox avec wireshark je peux transmettre les donnés
Merci d'avance pour votre aide
-
L'autre solution que je vois est de faire un firewall transparent, sur un bridge, et donc sans ip (et sans routage donc) dessus. C'est plus propre...
Tout est relatif quoi :p
-
Je ne vois pas vraiment comment ça pourrait être possible : il faudrait qu'à la fois l'équipement gérant le client dhcp et le fw aient l'ip en question. Alors certes, dhclient et autres utilisent généralement du raw socket, donc ça devrait pouvoir fonctionner, mais ça reste un hack sale.
L'autre solution que je vois est de faire un firewall transparent, sur un bridge, et donc sans ip (et sans routage donc) dessus. C'est plus propre...
oui un bridge L2 filtrant qui detag les vlan couplé a un "dhcp relay" qui ajoutent les options requises.
-
Le pire c'est que c'est exactement ça: Si la Livebox avait un mode bridge, elle serait devant mon routeur et je ne chercherais même pas à m'en passer...
On est bien d'accord, et ça fait minoritairement le jeu des FAI comme SFR/NC ou Free ou le mode bridge est omniprésent depuis des années....
-
regardez la norme pour l'option 90, https://tools.ietf.org/html/rfc3118. Orange s'est peut-etre mis a jour pour être rentrer dans la norme (ce qui n'était pas le cas avant) ? (on parle de rumeur de routeurs du commerce qui seraient bientot compatibles avec les connexions Orange).
le truc qui change a chaque renew ca serait pas le Replay Detection de la norme ?
Kgersen, ou as tu chopé cette info sur les routeurs du commerce stp ? Cela m’intéresse grandement ;-)
-
Bonjour
J'ai récemment update mon pfense à la version 2.4.4 cela à marcher à peine deux jours avec ipv4 et dhcp
puis depuis hier plus rien le renew dhcp ne marche plus j'ai essayé vos chaines pour l'option 90
de plus j'ai l'impression que l'option de prio dhcp ne marche pas quelqu'un fait des tests la nouvelle version de pfsense
si vous voulez j'ai utilisé l'outil liveboxbox info et j'ai fait un snif sur le port wan ma livebox avec wireshark je peux transmettre les donnés
Merci d'avance pour votre aide
-
Kgersen, ou as tu chopé cette info sur les routeurs du commerce stp ? Cela m’intéresse grandement ;-)
https://www.nextinpact.com/brief/netgear-travaille-bien-a-l-utilisation-de-certains-de-ses-routeurs-comme-modem-fibre-orange-5554.htm
Par contre le prix risque de piquer et quid de la téléphonie ?
-
Merci bcp Mirtouf ;-)
-
Bonsoir,
Tout d'abord merci pour le travail effectué, très appréciable :)
Avec la nouvelle authentification je me demande s'il n'y aurait pas d'autres changements, par exemple les options DHCP "spéciales" pour mettre la livebox derrière le routeur? (téléphonie TV etc..)
-
perso
le jour ou on pourra mettre des routes statiques je remet ma livebox devant mon pfsense
-
Bonjour les jeunes
Depuis le changement de la chaîne, j'ai bien retrouvé internet mais pas la TV ni le téléphone. Je suis sur ERL3, dernier firmware avec la config livebox en support pour le téléphone et en ipV4.
Merci pour votre aide.
schusss
-
EDIT : RAS la téléphonie fonctionne.
A voir cependant si par la suite Orange n'effectue pas des modifs là-dessus.
-
Salut les loulous.
Il se trouve que j'avais reversé la partie concernée du firmware Livebox 3 qui génère cette option DHCP, je vais donc vous faire part de mes notes.
[...]
Voilà pour mes notes les kidz ! Amusez-vous bien
Merci énormèment de ces infos , j'ai pu également faire les modifs.
Pour faire suite à ça, voici quelques pointeurs & commentaires.
* Option 77 (0x4D) : User-class, http://www.iana.org/go/rfc3004
=> Il semble que ce soit une valeur fixe dans les livebox ? A vérifier sur les livebox pro, ou sur des abo FTTH pro ?
* Option 61 (0x3D) : Client-id , http://www.iana.org/go/rfc2132
=> Le rfc mentionne "une valeur unique par client" , l'adresse MAC parait donc un choix pertinent .
Ces 2 options peuvent, comme actuellement, faire l'objet d'une configuration "en dur" dans la configuration des box alternatives dans l'état actuel des connaissances.
* Option 90 (0x5A) : Authentication, https://tools.ietf.org/html/rfc3118
=> Le RFC indique plusieurs méthodes , dont effectivement un système d'anti-rejeu qui ne semble actuellement pas implèmenté.
Par contre, après avoir lu ce RFC, je n'y retrouve pas l'algorithme décrit dans le thread pour le calcul des valeurs.
Ca pourrait vouloir dire qu'il faudrait gérer un patch spécifique à Orange sur odhcpc pour que l'on puisse garder les routeurs tiers (vu que le bridging est pas faisable sur livebox). Le patch ne semble pas très complexe à faire, mais bon, pour le faire intégrer upstream & sur OpenWRT .... :-/
En tout cas, merci pour ces info.
J'ai plusieurs DGA4030 / DGA4032 , mais apparemment un autre modèle qui marche sous OpenWRT serait le DM200 ( https://wiki.openwrt.org/toh/netgear/dm200 ) , basé sur un chipset lantiq (je n'ai pas testé) - qui donne un shell , à défaut d'être 100% libre.
-
Merci pour ces posts fort utiles ! J'ai remarqué le souci ce matin chez moi je viens de faire la modif et tout semble fonctionner comme avant maintenant.
-
Bonjour
Merci pour ces infos 5h a essayer de comprendre pourquoi a 00h10 coupure mystère et impossible pour mon router de ce connecter
manip effectuée :
Connexion SFTP sur Routeur
éditer le fichier "/config/config.boot"
Remplacer : 00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
par le pattern mis sur le premier post de @Mastah
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Connexion http://Router
Redémarrage
Tous re-fonctionne par magie
Je ne suis pas sur que ma méthode édition direct du fichier "config.boot" en sftp est valide, donc si je devais faire un chargement d'un fichier .boot comme dans les tuto ou si cela n'aurais rien fait de plus quelqu'un peux t'il me le dire s'il vous plait.
Merci beaucoup pour toutes les infos
-
Bonjour,
L'algorithme présenté par "Gucci gang" semble correct.
C'est le même principe que le CHAP MD5 utilisé sur PPP (RFC 1994) : MD5_hash(Identifier, secret, Challenge)Sauf que dans le cas du CHAP, l'identifier (RANDCHAR) est une sorte de numéro de message (comme dans les paquets ICMP ping) et le Challenge (RANDSTRING) est généré aléatoirement par le serveur (celui qui demande l'authentification). Alors que dans le cas du DHCP Orange, ça semble être la Box qui génère elle-même plus ou moins aléatoirement l'octet Identifier (RANDCHAR) et les 16 octets du Challenge (RANDSTRING).
C'est bien un algorithme décrit dans la RFC 1994 (CHAP sur PPP) qui est utilisé ici par Orange et non celui de la RFC 3118 (authentification sur DHCP avec l'option 90 pour IPv4 ou option 11 pour IPv6). Les mécanismes d'authentification forte sur DHCP s'appuient sur un système complexe de clefs (utilisé par Cisco ?)
Chez Orange ils essaient toujours de se rattacher au bon vieux PPP des modems analogiques (d'où le PPPoE sur ADSL et les premières fibres). C'est plus facile pour eux d'identifier quel utilisateur (identifiant/mot de passe) utilise quelle IP à un instant donné.
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 !
Merci pour les infos dans ce sujet,
Laurent.
-
Merci également ! IP perdue hier fin d'après-midi, tout est rentré dans l'ordre après la modif.
-
IP perdue dans la nuit...
Un grand merci, cela a fonctionné du premier coup ! 8)
J'ai récupéré la même @IP (pas besoin de reconfigurer mes VPN). ;)
Au top ! 8)
-
L'algorithme présenté par "Gucci gang" semble correct.
C'est le même principe que le CHAP MD5 utilisé sur PPP (RFC 1994) : MD5_hash(Identifier, secret, Challenge)[...]
Chez Orange ils essaient toujours de se rattacher au bon vieux PPP des modems analogiques (d'où le PPPoE sur ADSL et les premières fibres). C'est plus facile pour eux d'identifier quel utilisateur (identifiant/mot de passe) utilise quelle IP à un instant donné.
Radius, plus que ppp, mais oui. Le radius est un protocole d'auth très flexible, et très bien maîtrisé chez les opérateurs et sur les équipements. Pas de soucis pour répondre à des milliers de requetes à la seconde.
-
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.
-
Bonjour les jeunes
Depuis le changement de la chaîne, j'ai bien retrouvé internet mais pas la TV ni le téléphone. Je suis sur ERL3, dernier firmware avec la config livebox en support pour le téléphone et en ipV4.
Merci pour votre aide.
schusss
Hello,
Je me réponds à moi-même, j'avais modifié la chaîne longue aussi sur la partie téléphonie. Bizarre que l'identification ne soit pas la même sur les 2 branches.
Du coup, ça fonctionne nickel pour tout.
Merci encore.
Schusss
-
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.
-
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...
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.
Si ça peut aider, j'utilise Python (SaltStack en fait) pour générer ma configuration DHCP ; voici les fonctions que j'utilise actuellement :
import os
import hashlib
def ord_chain(string, format = '%02x', delimiter = ':'):
result = []
for char in string:
try:
value = ord(char)
except TypeError:
value = char
result.append(format % value)
return delimiter.join(result)
def make_salt(length=16):
return os.urandom(length)
def make_orange_hash(salt, password, byte=None):
random_byte = os.urandom(1) if byte is None else byte
md5_hasher = hashlib.md5()
md5_hasher.update(random_byte)
md5_hasher.update(password)
md5_hasher.update(salt)
return random_byte + md5_hasher.digest()
if __name__ == '__main__':
# Test the "make_salt" function:
print(ord_chain(make_salt(10)))
# Test the "make_orange_hash" function:
print(ord_chain(make_orange_hash('saltsaltsaltsalt', '_password', 'a')))
-
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 ?)
-
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.
-
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 ?)
Je pense que xavier a raison : C'est pas tellement le mot de passe faux que le champ syntaxiquement incorrect qui a provoqué le rejet.
-
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.
-
Ya un bug avec https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.9-1/crypto-js.min.js
ReferenceError: CryptoJS is not defined
-
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 :P ). 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})
-
@hoyohoyo toutes tes chaines font la même longueur...
C'est juste que le forum utilise une police proportionnelle...
-
j'ai fait un générateur a la vite : https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/
Ma contribution en bash avec un minimum de dépendances (dd+ md5sum + sed + cut)
merci à tous les 2 !
Si cette méthode est / devient une norme (ou rfc), ptet une implèmentation dans odhcpc serait pertinent, non ?
(edit) En fait, ce message https://lafibre.info/remplacer-livebox/renew-dhcp-daujourdhui-gt-plus-dip/msg580486/#msg580486 propose une solution moins intrusive. A voir si un signal HUP permet de forcer la relecture de la config du client dhcp, mais si c'est le cas un simple script cron règlement les choses simplement et sans toucher à du code "juste" pour Orange.
-
@zoc j'ai testé à l'instant et ça fonctionne. Merci ;)
Cette valeur est à régénérer à chaque renew du dhcp, si j'ai bien compris ?
-
@zoc j'ai testé à l'instant et ça fonctionne. Merci ;)
Cette valeur est à régénérer à chaque renew du dhcp, si j'ai bien compris ?
Là, tout de suite... je ne pense pas. Mais si un jour Orange se met à implèmenter une Replay Detection Method digne de ce nom, alors on ne pourra plus se contenter de mettre une chaîne hexa en dur dans la configuration de nos clients DHCP. Il faudra au minimum incrèmenter la valeur du "monotonically-increasing counter" à chaque requête DHCP (actuellement on envoie toujours 0).
En complèment, voici les commentaires que j'ai écrits pour mon fichier de configuration DHCP : ils reprennent ce qu'a trouvé "gucci gang" tout en détaillant les fameux "11 0x00" qu'on se traîne tous depuis un bon moment :
# Option (90) Authentication:
# First, we have to define that option:
option authentication code 90 = string;
# Next, we strive to imitate what a LiveBox would generate, starting with
# 11 null bytes:
# - 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)
# Then, according to [1], we have a sequence of Type-Length-Value fields:
# - Unknown field: type 0x1A, length 9 (1+1+7), value 00:00:05:58:01:03:41
# - Username field: type 0x01, length 13 (1+1+11), our Orange PPP login, i.e. "fti/xxxxxxx"
# - Salt field: type 0x3C, length 18 (1+1+16), 16-byte random salt
# - Hash field: type 0x03, length 19 (1+1+17), 1 random byte followed by the 16-byte MD5 hash of:
# - that random byte
# - our Orange PPP password
# - the salt field
send authentication 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:{{ orange_login_hex }}:3c:12:{{ orange_salt_hex }}:03:13:{{ orange_hash_hex }};
# [1] https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/
Cela dit, ce serait bien de déterminer ce qu'est ce champ inconnu après les paramètres RDM...
-
# Then, according to [1], we have a sequence of Type-Length-Value fields:
# - Unknown field: type 0x1A, length 9 (1+1+7), value 00:00:05:58:01:03:41
Cela dit, ce serait bien de déterminer ce qu'est ce champ inconnu après les paramètres RDM...
1a:09:00:00:05:58:01:03:41 => 0x0558 = 1368.
1368 = Orange, cf https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers.
-
Pour les utilisateurs de FreeBSD, voici un script basé sur le travail de @zoc. Je travaille avec l'équipe OPNsense pour l'intégrer à l'interface graphique
#!/bin/sh
login='fti/abcdef'
pass='hijklmn'
tohex() {
for h in $(echo $1 | sed "s/\(.\)/\1 /g"); do printf %02x \'$h; done
}
#Fixed Part
f="00000000000000000000001a0900000558010341010d"
#RANDSTRING
r=$(dd if=/dev/urandom bs=1k count=1 2>&1 | md5 | cut -c1-16)
#RANDCHAR
id=${r%${r#??}}
#MD5 HASH (RANDCHAR+pass+RANDSTRING)
h=3c12$(tohex ${r})0313$(tohex ${id})$(echo -n ${id}${pass}${r} | md5 | cut -c1-32)
#Dhcp Authorisation string (FIXED+LOGIN+MD5HASH)
option90=$(echo "${f}$(tohex ${login})${h}" | sed 's/\(..\)/\1:/g' | sed '$s/.$//')
echo $option90
-
Ya un bug avec https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.9-1/crypto-js.min.js
ReferenceError: CryptoJS is not defined
avec quel navigateur ? t'as un bloqueur de pub ou de scripts ?
-
Pour les utilisateurs de FreeBSD, voici un script basé sur le travail de @zoc. Je travaille avec l'équipe OPNsense pour l'intégrer à l'interface graphique
Eh, merci, ça fonctionne très bien sous open également, pas de bashismes comme dans la version de zoc (mais merci quand même !).
-
avec quel navigateur ? t'as un bloqueur de pub ou de scripts ?
Effectivement, c'était le bloqueur de pub qui a été trop zélé.
-
1a:09:00:00:05:58:01:03:41 => 0x0558 = 1368.
1368 = Orange, cf https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers.
Excellent ! On est donc clairement sur un champ de type "Vendor information" ; je suppose que 01:03:41 reflète la version du firmware de la Livebox ?
-
Bonjour !
Merci beaucoup pour vos recherches, j'ai enfin compris pourquoi je n'ai plus internet depuis vendredi soir (je n'étais pas chez moi, en plus)
Le changement est donc valable pour l'option 90 du DHCP. Mais qu'en est-il de l'IPv6, faut il changer la chaîne d'identification aussi ?
Merci !
-
Oui, pour l'IPv6, c'est l'option 11.
C'est strictement la même valeur pour les 2 (option 90 en IPv4 et option 11 en IPv6).
-
Excellent ! On est donc clairement sur un champ de type "Vendor information" ; je suppose que 01:03:41 reflète la version du firmware de la Livebox ?
Peut-être. Une autre possibilité serait que c'est une valeur en TLV : Type 0x01, Length 0x03, Value 0x41 (ascii A). De là à savoir ce que ça veut dire...
-
J'ai essayé tous les script posté et aucun ne marche, je n'obtiens pas d'IP.
La seul méthode qui a marché est celle décrite au début de ce sujet :
Le pattern qui semble fonctionner
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
-
Bonjour,
Je me permet de répondre car j'ai également été concerné par ce changement.
Ma configuration après modification
/etc/dhcp/dhclient.conf
###################################################################################################################################################################
send vendor-class-identifier "sagem";
option user-class code 77 = string;
send user-class 2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:4c:69:76:65:62:6f:78:34; #livebox[b]4[/b] a la fin
option authsend code 90 = string; #au lieu de rfc3118-authentication
send authsend 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:66:74:69:2f:XX:XX:XX:XX:XX:XX; #fti/
request subnet-mask, routers,
domain-name, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time;
supersede domain-name-servers 8.8.8.8 8.8.4.4;
# WAN
# ---------
allow-hotplug enp2s0f0
auto enp2s0f0 vlan832
iface enp2s0f0 inet manual
post-up /sbin/ip l s up dev $IFACE
# ------------------
# ON VLAN 832
# -----------------
iface vlan832 inet manual
pre-up /sbin/ip l a link enp2s0f0 name $IFACE type vlan id 832 egress-qos-map 0:6
post-up /sbin/dhclient $IFACE
pre-down /sbin/dhclient -r $IFACE || true
post-down /sbin/ip l d $IFACE
J'ai mis plus de détails sur https://debian.ovh/Orange%20VLAN832%20%28DHCP%29/ (https://debian.ovh/Orange%20VLAN832%20%28DHCP%29/)
ps: je suis sous debian
voila voila si ca peut aider :)
-
J'ai essayé tous les script posté et aucun ne marche, je n'obtiens pas d'IP.
La seul méthode qui a marché est celle décrite au début de ce sujet :
j'avais un bug dans mon script je l'ai mis a jour: https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/
-
Peut-être. Une autre possibilité serait que c'est une valeur en TLV : Type 0x01, Length 0x03, Value 0x41 (ascii A). De là à savoir ce que ça veut dire...
ce n'est pas coherent car inclus dans le TLV d'avant. ou alors c'est un TLV dans un TLV?! curieux.
-
Avez-vous regarder si on retrouve des infos de 'deviceinfo' (avec https://www.liveboxinfo.ga/ ou en ligne de commande avec https://github.com/rene-d/sysbus ) dans les data envoyées dans la requete dhcp?
-
Bon ça pue tout ça... Des infos que j'ai, on est en periode transitoire avant l'activation du système d'authentification un peu plus agressif, qui interdira le rejeu, et donc, par extension, interdira tout bypass de la box. Pour l'instant, le serveur DHCP ne vérifie pas ce qui est envoyé, mais dans le futur, je ne vois aucune possibilité de bypass ça... :/
(En tout cas, bien joué pour le reverse engineering du firmware ! Mais je crains que ça ne suffise pas)
-
Oh, ça, ça pu vraiment effectivement :(
Pourquoi il font ça ? Franchement...
(j'imagine que c'est d'un point de vue sécurité évidemment, m'enfin...)
-
Pour nous obliger d’avoir leur livebox dans leur réseau
-
Mouais...
Je pense que ça va plus loin, on doit même pas être 1% de client avec son propre routeur...
-
Bon ça pue tout ça... Des infos que j'ai, on est en periode transitoire avant l'activation du système d'authentification un peu plus agressif, qui interdira le rejeu, et donc, par extension, interdira tout bypass de la box. Pour l'instant, le serveur DHCP ne vérifie pas ce qui est envoyé, mais dans le futur, je ne vois aucune possibilité de bypass ça... :/
(En tout cas, bien joué pour le reverse engineering du firmware ! Mais je crains que ça ne suffise pas)
Quelles sont tes sources ?
-
Quelles sont tes sources ?
Des gens chez Orange.
-
Dans l'idée il y aura forcement un moyen de refaire ce que fait la livebox.
Je vais me lancer dans le developpement d'un dhcp client special FAI
-
Ben justement non. Si on commence à avoir des hashs et une base de salts anti rejeu côté Orange, ça va être de plus en plus tendu...
-
Dans la theorie il suffit de connaitre l'algo de la box. Complexe mais il y a moyen. On extrait facilement un dump du trafic c est deja un gros coup de pouce (je motive)
-
Heu, t’as lu les 8 pages d’avant ? ::)
-
Je ne vois pas de difficulté particuliere vu qu'on sait désosser les firmwares des livebox (pour recup une éventuelle table de salt, etc). Il faudra juste coder un client dhcp particulier.
Mais j'aimerai bien connaitre leur motivation pour mettre autant de complexité dans leurs systèmes. Je ne pense pas que ce soit a cause de ceux qui remplacent leur livebox, c'est tellement peu en pourcentage et on ne gagne rien et ca n'impacte pas leur réseau.
C'est pour activer le mode DHCP pour les offres Pro peut-être ? ou proposer des routeurs alternatifs d'OEM certifiés par Orange ?
-
Je vote pour les routeurs alternatifs, cela ferait sens avec les rumeurs de ces derniers temps.
-
Netgear n’a pas développé son firmware avec Orange et la modif a tout cassé chez les Bêta Testeurs.
-
Donc la piste ip fixe pour les pros est peut-être la bonne, finalement.
-
Dans l'idée il y aura forcement un moyen de refaire ce que fait la livebox.
Je vais me lancer dans le developpement d'un dhcp client special FAI
vaut mieux que tu fasse des merge/pull request sur un client dhcp existant pour rajouter des features aux clients DHCP existant. ça evitera d'avoir une cinquentaine de client différent qui font la même chose. autant prendre celui qui est le plus connu utilisé et libre et rajouter les features qu'on a besoin dessus ::)
-
Aucune chance qu'un pull request qui ne correspond à aucune RFC ne soit acceptée sur un dépôt un tant soit peu sérieux...
-
A moins de proposer un PR qui appele un script shell permettant d'ajouter/modifer des options DHCP a une requete sortante. un truc tres générique.
-
Je trouve que vous faites un peu des plans sur la comete... Pour l'instant rien de tout ça n'est nécessaire.
-
oui faudrait plutôt juste faire un bon lobbying envers Orange pour qu'ils développent un mode bridge ;p
-
Je trouve que vous faites un peu des plans sur la comete... Pour l'instant rien de tout ça n'est nécessaire.
Ah mais moi je ne fais aucun plan sur la comète :)
Pour l’instant je me suis contenté de sniffer ce qui sort de la box et copier/coller le contenu de l’option 90. Ca restera comme ça chez moi tant que ça fonctionnera.
-
A propos, je me demande comment on peut avoir un mode bridge et en même temps conserver le téléphone sur la box depuis que celui-ci est sur le 832 avec la nouvelle archi.
En prenant l'ancienne archi pppoe c'est facile, il suffit ne faire passer que le 835 et laisser le 838∕840/851 à la box, mais en DHCP ?
-
Bon ça pue tout ça... Des infos que j'ai, on est en periode transitoire avant l'activation du système d'authentification un peu plus agressif, qui interdira le rejeu, et donc, par extension, interdira tout bypass de la box. Pour l'instant, le serveur DHCP ne vérifie pas ce qui est envoyé, mais dans le futur, je ne vois aucune possibilité de bypass ça... :/
(En tout cas, bien joué pour le reverse engineering du firmware ! Mais je crains que ça ne suffise pas)
J'espère que ça tombera à l'eau... Changer de FAI juste parcequ'on ne peut utiliser son propre routeur (sans double nat évidemment...), ça me ferait bien ch...
-
A propos, je me demande comment on peut avoir un mode bridge et en même temps conserver le téléphone sur la box depuis que celui-ci est sur le 832 avec la nouvelle archi.
avec IPv6 ou un pseudo bridge comme fait la Freebox. Mais de toute façon Orange n'a pas l'air de prendre cette voie.
-
Sagem, qui est le fournisseur d'Orange en LB4, a une solution qu'il fournit à SFR pour les box FTTLa (qui ont un mode bridge parfaitement fonctionnel).
La box a tout simplement 2 IPv4 publiques, une pour le bridge (forwardé au routeur) et une autre pour les services propres à la box dont le téléphone (mais aussi la VoD/Replay puisqu'il s'agit d'une box tout en 1).
-
Personne a réussi à entrer dans la livebox un genre ssh ou les fichier sources ?
-
avec IPv6 ou un pseudo bridge comme fait la Freebox. Mais de toute façon Orange n'a pas l'air de prendre cette voie.
Ipv6 mais bien sûr, pour quoi j'y ai pas pensé, faut que je réfléchisse plus la prochaine fois.
Par contre pour le pseudo-bridge ça m'intrigue, l'ip est en quelque sorte partagé entre la FB et le routeur (un peu comme le CG-NAT qui utilise une partie des ports ?) ou c'est totalement différent ?
Sagem, qui est le fournisseur d'Orange en LB4, a une solution qu'il fournit à SFR pour les box FTTLa (qui ont un mode bridge parfaitement fonctionnel).
La box a tout simplement 2 IPv4 publiques, une pour le bridge (forwardé au routeur) et une autre pour les services propres à la box dont le téléphone (mais aussi la VoD/Replay puisqu'il s'agit d'une box tout en 1).
Ah d'accord c'est aussi bête que ça. Bon par contre c'est moyen pour la pénurie d'adresses.
Finalement Orange aurait peut-être mieux fait de garder le tel dans un VLAN dédié avec une ip privée.
-
Personne a réussi à entrer dans la livebox un genre ssh ou les fichier sources ?
Il y a eu un site en ligne pendant une courte période qui contenait des fimwares de livebox, mais à peine quelques jours après en avoir parlé ici même, pouf, il n'était plus disponible.
J'ai néanmoins récupéré 2-3 fichiers à la main, et j'ai vu dans l'un d'entre eux qu'il y avait apparemment un accès SSH sur le WAN sur un port spécifique autorisé pour seulement quelques ip du réseau Orange. Mais après c'est pas le tout, il faut le mot de passe, et lui, on l'a pas...
-
J'espère que ça tombera à l'eau... Changer de FAI juste parcequ'on ne peut utiliser son propre routeur (sans double nat évidemment...), ça me ferait bien ch...
Je commence à y songer :p
-
Sagem, qui est le fournisseur d'Orange en LB4, a une solution qu'il fournit à SFR pour les box FTTLa (qui ont un mode bridge parfaitement fonctionnel).
La box a tout simplement 2 IPv4 publiques, une pour le bridge (forwardé au routeur) et une autre pour les services propres à la box dont le téléphone (mais aussi la VoD/Replay puisqu'il s'agit d'une box tout en 1).
T’es sûr que c’est deux IPs publiques ? Je ne vois pas trop de raison d’avoir une IP publique sur un LAN qui ne sort pas du FAI.
-
Je commence à y songer :p
Vivement que BT arrive dans mon coin (pas envie de repasser chez SFR...).
-
T’es sûr que c’est deux IPs publiques ? Je ne vois pas trop de raison d’avoir une IP publique sur un LAN qui ne sort pas du FAI.
Oui il a raison.
-
j'ai egalement eu le soucis.
la modification a bien jouer sont role, mias du coup, je me pose egalement la question du bridge.
pour ceux qui ont testé, la partie DMZ joue pas un role equivalent et suffisant?
-
Il me semble également qu'on parle ici de plans sur la comète, essentiellement parce que les infos données ici sont très succintes.
Réflechissons un peu : je vois plusieurs façons d'empêcher le "replay" tel qu'on le fait tous actuellement :
1. utiliser les champs Replay Detection de la RFC 3118 ; typiquement, la valeur actuelle stipule "monotonically increasing value", ce qui implique de fournir le timestamp courant côté client pour que le serveur le compare après réception et rejette la requête si le timestamp est trop loin dans le passé. C'est assez léger à implèmenter côté serveur, et s'il n'y a que ça à faire pour continuer à envoyer bêtement le même trio user/salt/hash, on devrait s'en sortir, même si ça implique de patcher le client DHCP ou d'en trouver un qui implèmente correctement la RDM.
2. stocker côté serveur les données envoyées par les clients (par exemple les salts). C'est beaucoup plus lourd côté Orange, parce qu'il faut un système de stockage accessible à tous les nœuds DHCP, il faut se palucher la purge des données les plus anciennes, les sauvegardes, etc. Bref, ça commence à faire beaucoup de boulot de leur côté pour pas grand chose. Là encore, ça implique de patcher le client DHCP, avec du code plus compliqué (générer un nouveau salt, etc.) mais ça reste faisable.
3. méthode #1 + déterminer les salts acceptables à partir du login PPP et du timestamp courant avec un algorithme propriétaire... ok, là, ça n'implique pas de stockage côté Orange (un simple calcul permettant de définir si le salt fourni est made-in-Livebox ou non) et côté client, il faudrait se coltiner le reverse-engineering du firmware pour déterminer cet algorithme. C'est un peu le pire scénario catastrophe que je vois pour l'obtention d'un bail DHCPv4.
Pour ma part, je vais regarder comment ça se passe côté IPv6 chez Orange... si c'est plus simple d'avoir une connectivité IPv6 Orange, je peux parfaitement me passer de la connectivité IPv4 Orange...
Edit: bon, le DHCP IPv6 envoie les mêmes infos que le DHCP IPv4 a priori...
-
Ça part du principe que la pragmatisme règne chez Orange ça :D
-
Ok, le français n'est que ma deuxième langue. Donc, excuses si ce n'est pas la phrase bien. Mais quelque chose à propos de la nouvelle option-90 md5hash me préoccupe. Orange connaît notre identifiant et mot de passe. Mais à moins que je ne me trompe si la Livebox applique MD5 à RANDCHAR + PASSWORD + RANDSTRING dans son ensemble, elle ne pourrait jamais valider le mot de passe sur le serveur. Comment pourraient-ils obtenir la même chaîne aléatoire? MAIS s'ils ont juste inséré le mot de passe de hachage MD5 entre RANDCHAR et RANDSTRING, ils peuvent alors extraire le hachage du mot de passe et le comparer au hachage du mot de passe créé sur le serveur. Donc je pense que c'est incorrect
commentaires
-
Ben justement non. Si on commence à avoir des hashs et une base de salts anti rejeu côté Orange, ça va être de plus en plus tendu...
Hello, tout d'abord merci pour tes infos.
Une base des salts veut aussi dire possiblement une rotation de ceux-ci... ça s'annonce difficile :/
Et si on arrive -difficilement- à déterminer les salts, Orange pourrait à tout moment décider de les rendre inutilisable avec une mise à jour, il faudrait alors en trouver d'autres et ainsi de suite...
Maintenant, c'est quoi le but? Empêcher radicalement l'utilisation de son propre routeur? C'était la norme en ADSL de fournir les identifiants pour que le client installe son modem. En quoi ça pose problème sur la fibre? >:(
D'ailleurs n'y a t-il pas une obligation légale que l'opérateur fournisse un minimum d'intéropérabilité pour l'accès à ses services en dehors de son matériel?
Par analogie sur le mobile, c'est comme si Orange fournissait une SIM dont la méthode de déverouillage était propriétaire, de sorte à obliger les clients d'acheter ses mobiles.
Si Orange met tout ça en place, une fois mon engagement terminé : bye bye.
Ok, le français n'est que ma deuxième langue. Donc, excuses si ce n'est pas la phrase bien. Mais quelque chose à propos de la nouvelle option-90 md5hash me préoccupe. Orange connaît notre identifiant et mot de passe. Mais à moins que je ne me trompe si la Livebox applique MD5 à RANDCHAR + PASSWORD + RANDSTRING dans son ensemble, elle ne pourrait jamais valider le mot de passe sur le serveur. Comment pourraient-ils obtenir la même chaîne aléatoire? MAIS s'ils ont juste inséré le mot de passe de hachage MD5 entre RANDCHAR et RANDSTRING, ils peuvent alors extraire le hachage du mot de passe et le comparer au hachage du mot de passe créé sur le serveur. Donc je pense que c'est incorrect
commentaires
Je suppose que Randchar/randstring représentent un "challenge", une méthode équivalente existe pour le CHAP :
MD5_hash(Identifier, secret, Challenge)
si je comprend bien, "secret" est le salt (non communiqué et connu des 2 parties). ça change tout :-[
-
Ah non non ; si on reprend la description de "gucci gang", on a :
MD5(RANDCHAR + PASSWORD + RANDSTRING)
le password est connu d'Orange, ils n'ont qu'à faire un lookup du username fourni
le RANDCHAR est l'octet juste avant le hash MD5 transmis donc il est connu
le RANDSTRING (salt) est également transmis
Donc Orange a tout ce qu'il faut pour vérifier le mot de passe.
Ici, le MD5 n'est utilisé que comme une approche maladroite pour ne pas transmettre le mot de passe en clair. Sauf que, comme je l'ai signalé dans un autre post, ce mécanisme est très facile à bruteforcer et un attaquant bien équipé devrait pouvoir retrouver le mot de passe originel en 10 minutes.
-
Ok, le français n'est que ma deuxième langue.
C'est quoi ta première langue ? On peut peut-être faire un effort...
-
Ah non non ; si on reprend la description de "gucci gang", on a :le password est connu d'Orange, ils n'ont qu'à faire un lookup du username fourni
le RANDCHAR est l'octet juste avant le hash MD5 transmis donc il est connu
le RANDSTRING (salt) est également transmis
Donc Orange a tout ce qu'il faut pour vérifier le mot de passe.
Ici, le MD5 n'est utilisé que comme une approche maladroite pour ne pas transmettre le mot de passe en clair. Sauf que, comme je l'ai signalé dans un autre post, ce mécanisme est très facile à bruteforcer et un attaquant bien équipé devrait pouvoir retrouver le mot de passe originel en 10 minutes.
Oui c'est l'info qu'on avait au début, et avec tout cela on a tout pour pouvoir "forger" soi-même les requetes et ainsi bypasser la box tranquillement.
Maintenant l'ami Hugues nous apporte d'autres informations...
Bon ça pue tout ça... Des infos que j'ai, on est en periode transitoire avant l'activation du système d'authentification un peu plus agressif, qui interdira le rejeu, et donc, par extension, interdira tout bypass de la box. Pour l'instant, le serveur DHCP ne vérifie pas ce qui est envoyé, mais dans le futur, je ne vois aucune possibilité de bypass ça... :/
(En tout cas, bien joué pour le reverse engineering du firmware ! Mais je crains que ça ne suffise pas)
-
anglais mais j'aime pratiquer le français
-
anglais mais j'aime pratiquer le français
Tu te débrouilles bien ;)
-
anglais mais j'aime pratiquer le français
Ok, so basically, everything required to compute the MD5 hash is transmitted in the DHCP request, except of course the password itself:
- the random character/byte (which acts as a salting prefix) is transmitted right before the 16-byte MD5 hash itself
- the random string (which acts as a salting suffix) is transmitted too
Orange is supposed to know the expected password (they just have to lookup the provided username in their databases). If they have the random character, the password and the random string, they can compute the MD5 hash, compare it to the provided one and determine whether the provided password is correct.
This is essentially a lousy way to avoid transmitting the password in the clear. So lousy that a well-equipped attacker ought to be able to bruteforce the actual password in less than 10 minutes.
-
Oui c'est l'info qu'on avait au début, et avec tout cela on a tout pour pouvoir "forger" soi-même les requetes et ainsi bypasser la box tranquillement.
Maintenant l'ami Hugues nous apporte d'autres informations...
oui ça aurait du sens
-
Oui c'est l'info qu'on avait au début, et avec tout cela on a tout pour pouvoir "forger" soi-même les requetes et ainsi bypasser la box tranquillement.
Maintenant l'ami Hugues nous apporte d'autres informations...
D'autres informations floues, vagues, et peu cohérentes avec le contenu actuel des requêtes... une période de transition durant laquelle les nouvelles données transmises ne sont pas vérifiées a du sens. Mais pourquoi s'emmerder avec une période de transition durant laquelle le salt et le random byte sont transmis si c'est pour les enlever plus tard ?
-
Peut-être qu'il leur faut encore implèmenter la gestion des salts, dans la box, la vérification côté serveurs, etc...
Mise en place prématurée de ce système avant mise en prod, probablement :-\
-
Franchement, vu la transmission actuelle toute moisie du mot de passe, je ne m'attends pas à un mécanisme qui casse trois pattes à un canard...
-
D'autres informations floues, vagues, et peu cohérentes avec le contenu actuel des requêtes... une période de transition durant laquelle les nouvelles données transmises ne sont pas vérifiées a du sens. Mais pourquoi s'emmerder avec une période de transition durant laquelle le salt et le random byte sont transmis si c'est pour les enlever plus tard ?
Parce que passer brutalement d’un système à l’autre, ça veut dire mettre à jour exactement en même temps toutes les liveboxes et également tous les routeurs de bordures. Dans les deux cas de figure, c’est complètement impossible.
-
Je ne nie pas la nécessité d'une période de transition hein... je dis juste qu'une période de transition durant laquelle on transmet des informations (ici : le salt) juste pour le fun, ça n'a pas de sens.
Ce qui aurait le plus de sens c'est :
- on commence par transmettre les informations, on les vérifie côté serveur mais on ne refuse pas de répondre aux requêtes si la vérification échoue.
- quand les stats indiquent qu'on reçoit un pourcentage significatif de requêtes DHCP comportant ces informations, on passe la vérification à la vitesse supérieure et on commence à refuser de répondre.
Donc je tablerais sur une stabilisation des informations envoyées et, dans quelques semaines/mois, un contrôle de ces informations.
-
Le LFBN, l'impèmentation actuelle de DHCP et compagnie chez Orange, est une architecture de transition. Et des infos que j'ai de la nouvelle, ça m'inquiète, voilà tout :)
-
LFBN c'est dans les reverses dns uniquement, c'est "FBN" le projet (https://lafibre.info/orange-les-news/signification-des-reverse-dns-chez-orange/msg103748/#msg103748) :)
-
Ah merci, j'avais un doute ^^
-
j'ai egalement eu le soucis.
la modification a bien jouer sont role, mias du coup, je me pose egalement la question du bridge.
pour ceux qui ont testé, la partie DMZ joue pas un role equivalent et suffisant?
La DMZ marche correctement de mon expérience mais il y a des inconvénients :
double NAT,
plus d'internet quand la boiboîte a décidé toute seule de maj son firmware ou pire de se planter comme une grande, cela te rend dépendant d'un truc dont on se passait bien pour accéder au net.
cela ne résoud pas le problème de la TV,
et on n'est pas à l'abri des gags du genre impossible de joindre 1.1.1.1, comme en avril ;)
-
Le LFBN, l'impèmentation actuelle de DHCP et compagnie chez Orange, est une architecture de transition. Et des infos que j'ai de la nouvelle, ça m'inquiète, voilà tout :)
As-tu moyen de nous transmettre un maximum d'informations techniques objectives et fiables ? Il nous faut idéalement savoir quel genre de challenge nous attend pour mieux nous y préparer. Personnellement, je suis parfaitement préparé à devoir patcher isc-dhclient (ou à trouver un client DHCP alternatif plus facile à personnaliser) et à partager le code ainsi produit, mais ce qui m'intéresse le plus, c'est à quel point les échanges DHCP dépendront :
- d'algorithmes inconnus server-side
- de données difficilement extractibles livebox-side (certificat client, clé privée, ...)
- de communications entre les infrastructures d'Orange et la Livebox ("eh, livebox #345215, voici ton nouveau certificat client valable une semaine seulement")
-
Franchement il vaut mieux se taire et rien dire que de dire 'j'ai des infos' et rien plus. Ca n'apporte rien a la discussion. Si vous avez besoin de flatter votre égo, ouvrez un sujet dans le bistro , ca sert a ca.
-
Trop drôle.
Les infos que j'ai eues elles sont simples : L'auth DHCP va se complexifier, y'aura de l'anti rejeu. J'en sais pas plus, mais mon interlocuteur était assez pessimiste sur la possibilité de bypass le futur système (et il est dans un service bien informé).
-
- d'algorithmes inconnus server-side
- de données difficilement extractibles livebox-side (certificat client, clé privée, ...)
- de communications entre les infrastructures d'Orange et la Livebox ("eh, livebox #345215, voici ton nouveau certificat client valable une semaine seulement")
Un bon délire technologique pour emm... les quelques technophiles du dimanche qui utilisent leur propre équipement.
Leur intérêt concret dans la manip ? A part frustrer gratuitement quelques clients.
Ou bien installer dans chaque LB quelque bigbrother qu'il serait trop lourd de placer sur le backbone ?
Désolé pour le mode bistrot :)
-
Je ne nie pas la nécessité d'une période de transition hein... je dis juste qu'une période de transition durant laquelle on transmet des informations (ici : le salt) juste pour le fun, ça n'a pas de sens.
Ce qui aurait le plus de sens c'est :
- on commence par transmettre les informations, on les vérifie côté serveur mais on ne refuse pas de répondre aux requêtes si la vérification échoue.
- quand les stats indiquent qu'on reçoit un pourcentage significatif de requêtes DHCP comportant ces informations, on passe la vérification à la vitesse supérieure et on commence à refuser de répondre.
Donc je tablerais sur une stabilisation des informations envoyées et, dans quelques semaines/mois, un contrôle de ces informations.
Il me semble que Orange est bien plus avancé dans son plan de déploiement. qu'on peut le penser.
* Les LB envoient ces options 90 avec les champs random etc depuis plus d'un an, sans qu'ils soient contrôlés, tant en terme de format que de validité du hash, par leurs seveurs DHCP. Le temps de mettre à jour le parc, finaliser les devs et préparer la mise en production.
* Orange décide comme ça la semaine dernière de bloquer les requêtes n'étant pas à ce nouveau format :
il y a de fortes chances qu'ils soient maintenant prêts à contrôler le contenu, au delta de temps près pour effectivement identifier et patcher les dernières rebelles :)
-
L'auth DHCP va se complexifier, y'aura de l'anti rejeu. J'en sais pas plus, mais mon interlocuteur était assez pessimiste sur la possibilité de bypass le futur système.
Je pense que c'est là où les informations apportées sont trop parcellaires : l'ajout d'« anti-rejeu » ne réduit pas spécialement « la possibilité de bypass le futur système », à la regrettable exception toutefois de ceux qui n'ont pas les moyens de mettre à jour le code de leur client DHCP. Pour que le « futur système » soit vraiment difficile à bypasser, il faudrait de la crypto, beaucoup plus de crypto que ce MD5. Wait & See donc.
Un bon délire technologique pour emm... les quelques technophiles du dimanche qui utilisent leur propre équipement.
Leur intérêt concret dans la manip ? A part frustrer gratuitement quelques clients.
Ou bien installer dans chaque LB quelque bigbrother qu'il serait trop lourd de placer sur le backbone ?
Aucune idée... je suis trop habitué aux délires incessants des technos propriétaires, du Not Invented Here et du Théâtre de la Sécurité pour me poser la question.
Il me semble que Orange est bien plus avancé dans son plan de déploiement. qu'on peut le penser.
Oui, tout à fait, on approche clairement de la dernière phase avec contrôle complet.
-
En ce qui me concerne, résiliation demandée hier.
Je n'arrive pas à comprendre cette stratégie stupide.
L'herbe sera certainement plus verte ailleurs avec une box gérant le bridge!
-
En ce qui me concerne, résiliation demandée hier.
Je n'arrive pas à comprendre cette stratégie stupide.
L'herbe sera certainement plus verte ailleurs avec une box gérant le bridge!
Je ne vois pas ce qui est de meilleur avoir une box gérant le bridge .... consommer plus ?
ONT -> Box -> Routeur Franchement je ne trouve pas top , c'est mieux avoir ONT - > Routeur sauf si t'aime avoir pleins d'appareil :)
-
En ce qui me concerne, résiliation demandée hier.
Je n'arrive pas à comprendre cette stratégie stupide.
L'herbe sera certainement plus verte ailleurs avec une box gérant le bridge!
À quel fournisseur allez-vous vous déplacer?
-
Je ne vois pas ce qui est de meilleur avoir une box gérant le bridge .... consommer plus ? ONT -> Box -> Routeur Franchement je ne trouve pas top , c'est mieux avoir ONT - > Routeur sauf si t'aime avoir pleins d'appareil :)
J'ai juste besoin d'une connexion stable, sans devoir trembler à chaque renew DHCP...
J'utilise l'edgerouter pour faire de la redondance entre deux connexions, du VPN entre deux sites. Être suspendu à ce type de changement ne m'enchante pas tellement
À quel fournisseur allez-vous vous déplacer?
Je vais tester Free, j'ai toujours SFR coax 400/40 en backup si cela ne me convient pas, le temps de tester autre chose.
Je crois qu'il n'est pas possible à ce jour de remplacer le FBX par un edge, en ZTD ?
-
Je crois qu'il n'est pas possible à ce jour de remplacer le FBX par un edge, en ZTD ?
non ce n'est pas possible actuellement.
et d’expérience avec une freebox en bridge, la connexion est plus rapide et stable en double nat qu'en bridge.............
Il me semble que ce n'est pas le bon moment de passer de Bouygues à Orange pour avoir un meilleur support sur routeur Openwrt ?
-
Il me semble que ce n'est pas le bon moment de passer de Bouygues à Orange pour avoir un meilleur support sur routeur Openwrt ?
Si l'on écoute Hugues, effectivement, il vaut peut-être mieux patienter quelques temps...
-
J'ai juste besoin d'une connexion stable, sans devoir trembler à chaque renew DHCP...
Idem.
D'ailleurs, en parlant de ça, je vois ce matin (mon premier RENEW a eu lieu hier soir, donc je ne sais pas si c'est lié à ça...) que je ne dépasse plus les 120 Mbits/sec. en débit descendant (Sur une offre Jet), aussi bien e IPv6 qu'en IPv4. J'ai par contre toujours les 300 Mbits/sec. montants... Je ne sais pas si c'est juste moi ou une nouvelle fourberie d'Orange (et malheureusement chez moi en FTTH c'est soit Orange soit rien).
testé avec iperf3
-
Le plus propre serait de demander aux mainteneurs des clients DHCP (udhcpc pour IPv4, odhcp6c pour IPv6 sous OpenWrt) de mettre en place un mécanisme de hook/callback pour faire appel à un programme ou un script externe pour générer dynamiquement une option à chaque requête envoyée par le client.
Les clients DHCP utilisent déjà l’appel d’un script pour mettre à jour le système (adresse IP des interfaces, routes, serveurs DNS …) en fonction des réponses du serveur DHCP.
Le procédé reste assez générique et on pourra fournir facilement un bout de script pour générer dynamiquement l’option 90 (ou 11 en DHCPv6) en changent le challenge random à chaque fois.
Certains FAI (hors de France) collaborent intelligemment avec les fabriquant de Routeurs et les mainteneurs de firmware Open Source (exemple ajout de l’option "noserverunicast" pour le DHCPv6 pour assurer la compatibilité des routeurs OpenWrt avec Fibre7)
Dans le pire des cas, le lease est de 3 jours, on peut se contenter de redémarrer le client DHCP avec une nouvelle chaîne d’authentification toutes les 63 heures...
-
Idem.
D'ailleurs, en parlant de ça, je vois ce matin (mon premier RENEW a eu lieu hier soir, donc je ne sais pas si c'est lié à ça...) que je ne dépasse plus les 120 Mbits/sec. en débit descendant (Sur une offre Jet), aussi bien e IPv6 qu'en IPv4. J'ai par contre toujours les 300 Mbits/sec. montants... Je ne sais pas si c'est juste moi ou une nouvelle fourberie d'Orange (et malheureusement chez moi en FTTH c'est soit Orange soit rien).
testé avec iperf3
J'ai eu aussi un renew hier soir, et pas de soucis de débit ici (toujours les 94x mb en down, zone avec CoS nécessaire, je précise au cas où ça aussi viendrait à avoir une incidence dans tout le bordel qu'est orange... Question, remplace la sfr box, c'est plus simple qu'Orange ? :o )
-
Question, remplace la sfr box, c'est plus simple qu'Orange ? :o )
Pour Sfr le net c'est très simple : il suffit d'envoyer un vendor class id -ipv6 c'est un tunnel l2tp , (ipv6 natif en cours ?= - pour la tv aucune idée
https://bitsofnetworks.org/utiliser-ipv6-chez-sfr-sans-la-neufbox-fr.html
Pour Bouygues (si déjà...) vendor class id et adresse mac de la box . Pour ma part juste tv en streaming (pas de replay ou iptv fonctionelle) pas d'ipv6
-
Je ne sais pas trop quoi répondre à tout ça. Ces modifications d'ingénierie ne sont bien sûr pas faites pour empêcher les utilisateurs de se connecter avec un routeur tiers, mais en prévisions d'évolution de plateformes ou de réseau de collecte. Certes, cela complique un peu les choses quand il y a un changement. Mais ce n'est pas tous les jours quand même !
J'ai demandé à ma hiérarchie, bien concernée par ces modifications d'architecture de collecte, s'il était possible de communiquer par exemple sur assistance.orange.fr sur les paramètres à envoyer au dhcp. J'attends une réponse.
Quoi qu'il en soit, je ne pense pas qu'il faille s'inquiéter pour l'instant. Il y a une solution statique qui fonctionne et qui ne demande pas de hook ou autre dans les clients dhcp, et a priori ça va fonctionner comme ça pendant un bon bout de temps.
(Avant on avait du pppoe et des ipv4 dynamiques, les gens se plaignaient. Orange fournit un service dual stack natif avec des ipv4 et v6 stables, et les gens se plaignent toujours...)
-
Idem.
D'ailleurs, en parlant de ça, je vois ce matin (mon premier RENEW a eu lieu hier soir, donc je ne sais pas si c'est lié à ça...) que je ne dépasse plus les 120 Mbits/sec. en débit descendant (Sur une offre Jet), aussi bien e IPv6 qu'en IPv4. J'ai par contre toujours les 300 Mbits/sec. montants... Je ne sais pas si c'est juste moi ou une nouvelle fourberie d'Orange (et malheureusement chez moi en FTTH c'est soit Orange soit rien).
testé avec iperf3
Je touche du bois pour le moment on va dire (Je suis en région parisienne dans le 77)
(https://image.ibb.co/bsCtjK/2018_10_02_11_16_02_Kodi_KODIMEDIA_VNC_Viewer.png)
(https://image.ibb.co/ct5ePK/2018_10_02_11_14_40_Clipboard.png)
-
Je ne sais pas trop quoi répondre à tout ça. Ces modifications d'ingénierie ne sont bien sûr pas faites pour empêcher les utilisateurs de se connecter avec un routeur tiers, mais en prévisions d'évolution de plateformes ou de réseau de collecte. Certes, cela complique un peu les choses quand il y a un changement. Mais ce n'est pas tous les jours quand même !
J'ai demandé à ma hiérarchie, bien concernée par ces modifications d'architecture de collecte, s'il était possible de communiquer par exemple sur assistance.orange.fr sur les paramètres à envoyer au dhcp. J'attends une réponse.
Quoi qu'il en soit, je ne pense pas qu'il faille s'inquiéter pour l'instant. Il y a une solution statique qui fonctionne et qui ne demande pas de hook ou autre dans les clients dhcp, et a priori ça va fonctionner comme ça pendant un bon bout de temps.
(Avant on avait du pppoe et des ipv4 dynamiques, les gens se plaignaient. Orange fournit un service dual stack natif avec des ipv4 et v6 stables, et les gens se plaignent toujours...)
Sans vouloir troll, la vraie question c'est pourquoi nous devons arriver à tout ce "cinéma"...
Je n'ai pas remplacé la Livebox par pur plaisir de bidouiller, mais simplement pour avoir accès à des fonctionnalités basique d'un routeur.
Pour ce qui est de la documentation c'est une bonne chose si cela abouti.
Aussi, je rejoins les autres contributeurs ici en incitant Orange à contribuer avec les constructeurs pour intégrer leurs éventuelles spécificités.
La communauté peut avoir un certains poids auprès de solutions ouvertes, mais cela reste assez long quand on fait cavalier seul...
-
Idem.
D'ailleurs, en parlant de ça, je vois ce matin (mon premier RENEW a eu lieu hier soir, donc je ne sais pas si c'est lié à ça...) que je ne dépasse plus les 120 Mbits/sec. en débit descendant (Sur une offre Jet), aussi bien e IPv6 qu'en IPv4. J'ai par contre toujours les 300 Mbits/sec. montants... Je ne sais pas si c'est juste moi ou une nouvelle fourberie d'Orange (et malheureusement chez moi en FTTH c'est soit Orange soit rien).
testé avec iperf3
Ecoute j’ai eu exactement le même problème mais avant le changement d’authentification, donc je ne pense pas que ce soit lié ...
-
Aussi, je rejoins les autres contributeurs ici en incitant Orange à contribuer avec les constructeurs pour intégrer leurs éventuelles spécificités.
Avec les constructeurs et avec leurs clients : je n'aime pas l'idée qu'il faille être constructeur pour avoir le détail du contenu des options DHCP...
-
Ecoute j’ai eu exactement le même problème mais avant le changement d’authentification, donc je ne pense pas que ce soit lié ...
Et ? C'est revenu tout seul au débit nominal ?
-
Internet est tombé ce matin chez moi, sans doute à cause d'un souci de renew DHCP (je ne suis pas sur place pour le moment).
J'utilisais la réponse complète (avec mot de passe salté etc) fournie par la LB4. D'autres personnes dans le même cas ? Je vais essayer de dépêcher quelqu'un sur place pour la redémarrer, voir si le renew DHCP se fait, mais sinon possible qu'ils commencent à utiliser le no-rekey sur certaines régions ?
EDIT : Revenu après redémarrage... Bizarre quand même, avant le changement côté Orange je n'ai jamais eu ce genre de soucis avec mon pfSense.
-
Rfc3118
5.4 Key utilization
Each DHCP client has a key, K. The client uses its key to encode any
messages it sends to the server and to authenticate and verify any
messages it receives from the server. The client's key SHOULD be
initially distributed to the client through some out-of-band
mechanism, and SHOULD be stored locally on the client for use in all
authenticated DHCP messages. Once the client has been given its key,
it SHOULD use that key for all transactions even if the client's
configuration changes; e.g., if the client is assigned a new network
address.
Each DHCP server MUST know, or be able to obtain in a secure manner,
the keys for all authorized clients. If all clients use the same
key, clients can perform both entity and message authentication for
all messages received from servers. However, the sharing of keys is
strongly discouraged as it allows for unauthorized clients to
masquerade as authorized clients by obtaining a copy of the shared
key. To authenticate the identity of individual clients, each client
MUST be configured with a unique key. Appendix A describes a
Appendix A - Key Management Technique
To avoid centralized management of a list of random keys, suppose K
for each client is generated from the pair (client identifier [6],
subnet address, e.g., 192.168.1.0), which must be unique to that
client. That is, K = MAC(MK, unique-id), where MK is a secret master
key and MAC is a keyed one-way function such as HMAC-MD5.
Without knowledge of the master key MK, an unauthorized client cannot
generate its own key K. The server can quickly validate an incoming
message from a new client by regenerating K from the client-id. For
known clients, the server can choose to recover the client's K
dynamically from the client-id in the DHCP message, or can choose to
precompute and cache all of the Ks a priori.
By deriving all keys from a single master key, the DHCP server does
not need access to clear text passwords, and can compute and verify
the keyed MACs without requiring help from a centralized
authentication server.
To avoid compromise of this key management system, the master key,
MK, MUST NOT be stored by any clients. The client SHOULD only be
given its key, K. If MK is compromised, a new MK SHOULD be chosen
and all clients given new individual keys.
-
(Avant on avait du pppoe et des ipv4 dynamiques, les gens se plaignaient. Orange fournit un service dual stack natif avec des ipv4 et v6 stables, et les gens se plaignent toujours...)
Nan on se plaint juste qu'Orange restreint (volontairement ou non) l'utilisation d'un routeur tiers.
Comme dit un peu avant, s'il y avait des options avancées digne d'un routeur sur la livebox, il n'y aurait pas besoin de s'embêter à remplacer celle-ci :-\
-
Au vu des récents changements, est-ce le PPPoE va être arrêté plus rapidement que prévu ? Genre d'ici 1 an ? Ou il faudra avant ça éradiquer toutes les vieilles livebox à coup de MAJ ? (à la manière LB mini).
-
Un truc qui se passe "Plus vite que prévu" chez Orange ? :D
-
Sur un malentendu ;D
-
Un truc qui se passe "Plus vite que prévu" chez Orange ? :D
tous ces conseils mais pas de substance
-
Nan on se plaint juste qu'Orange restreint (volontairement ou non) l'utilisation d'un routeur tiers.
attends, ok il faut reverse-engineerer un peu la chaine de caractère, mais une fois copiée et mise en option 90 c'est bon. Pas besoin de patcher quoi que ce soit, n'importe quel client dhcp digne de ce nom fonctionne.
C'est pas non plus ouf comme manip non ?
(et je dis ça alors que je suis en adsl, donc clairement c'est plus compliqué pour moi qu'en ftth pour sniffer ça...)
-
Ouais alors chez Free c'est du spoof mac et du DHCP sur un VLAN sans rien d'autre, et ça marche même en statique, tu m'excuseras mais là, c'est simple.
-
J'ai demandé à ma hiérarchie, bien concernée par ces modifications d'architecture de collecte, s'il était possible de communiquer par exemple sur assistance.orange.fr sur les paramètres à envoyer au dhcp. J'attends une réponse.
Tu peux leur demander pourquoi ils ne développent pas un mode bridge ?
(Avant on avait du pppoe et des ipv4 dynamiques, les gens se plaignaient. Orange fournit un service dual stack natif avec des ipv4 et v6 stables, et les gens se plaignent toujours...)
Les gens se plaignent juste que des choses simples et de bon sens , comme des IP fixes, un remplacement facile (qui notamment respecte les standards du Net), un mode bridge, ou alors pouvoir mettre des routes internes sur le LAN, changer les serveurs DNS, etc ne soient pas fournis.
Autre exemple: ca sert a quoi de fournir un /56 en IPv6 et être limité a un /64 avec la LB et ne meme pas pouvoir ouvrir une IPv6 sur le firewall ?
C'est juste qu'on ne comprend la complexité inutile des solutions Orange.
-
...
C'est juste qu'on ne comprend la complexité inutile des solutions Orange.
La partie ident / box / dhcp /blabla est p'tet une prestation interne OBS ::)
-
Ouais alors chez Free c'est du spoof mac et du DHCP sur un VLAN sans rien d'autre, et ça marche même en statique, tu m'excuseras mais là, c'est simple.
De mémoire chez SFR c'est encore plus simple : juste un vlan et spécifier un vendor en DHCP.
C'est pas totalement plug-and-play non plus, mais presque. Ici Orange nous casse les b*****!
[/tapeUnScandale]
@petrus non c'est pas une manip super difficile, mais ça reste du chinois au néophyte, faut être assez calé tout de même.
-
Si Orange continue de compliquer la configuration pour avoir un routeur perso à la maison, je pense changer pour un autre FAI. SFR n'est pas une option, Bouygues non plus.
J'attends donc avec impatience l'arrivée d'OVH FTTH.
-
Tu peux leur demander pourquoi ils ne développent pas un mode bridge ?
Les gens se plaignent juste que des choses simples et de bon sens , comme des IP fixes, un remplacement facile (qui notamment respecte les standards du Net), un mode bridge, ou alors pouvoir mettre des routes internes sur le LAN, changer les serveurs DNS, etc ne soient pas fournis.
Autre exemple: ca sert a quoi de fournir un /56 en IPv6 et être limité a un /64 avec la LB et ne meme pas pouvoir ouvrir une IPv6 sur le firewall ?
C'est juste qu'on ne comprend la complexité inutile des solutions Orange.
Trops de fragmentations dans les équipes et tout ce beau monde pourtant compétant qui ne se parle pas entre eux
-
Tu peux leur demander pourquoi ils ne développent pas un mode bridge ?
Les gens se plaignent juste que des choses simples et de bon sens , comme des IP fixes, un remplacement facile (qui notamment respecte les standards du Net), un mode bridge, ou alors pouvoir mettre des routes internes sur le LAN, changer les serveurs DNS, etc ne soient pas fournis.
IP Fixe :
A la demande sur l'Espace Client pour basculer de Dynamique à Fixe et inversement : 👍
Configuré par défaut dans la config du serveur DHCP, comme SFR, ByTel et Free : 👎
-
Oh non, pas encore ce débat dynamique/fixe...
-
IP Fixe :
A la demande sur l'Espace Client pour basculer de Dynamique à Fixe et inversement : 👍
Configuré par défaut dans la config du serveur DHCP, comme SFR, ByTel et Free : 👎
non plz. Assumez votre utilisation d'Internet svp.
-
+8192
-
bon sinon on revient quand au topic? :P
-
Et ? C'est revenu tout seul au débit nominal ?
Bah non j'ai du tout (ONT et ERL) rebooter pour retrouvé mon débit.
-
Chui assez d'accord avec Petrus, vous vous prenez la tête pour pas grand chose.
Vu la complexité que représente la mise à jour d'un parc de plusieurs millions de Livebox, il est très peu probable qu'Orange s'amuse à changer la partie identification tous les quatre matin. La valeur précédente a fonctionné chez moi pendant des mois, la nouvelle valeur fonctionnera probablement pendant des mois voire des années.
La seule chose que l'on peut regretter c'est le manque de doc officielle qui oblige à faire du reverse-engineering à chaque changement.
-
Trops de fragmentations dans les équipes et tout ce beau monde pourtant compétant qui ne se parle pas entre eux
Tel est Orange, réalité ::)
-
Chui assez d'accord avec Petrus, vous vous prenez la tête pour pas grand chose.
Vu la complexité que représente la mise à jour d'un parc de plusieurs millions de Livebox, il est très peu probable qu'Orange s'amuse à changer la partie identification tous les quatre matin. La valeur précédente a fonctionné chez moi pendant des mois, la nouvelle valeur fonctionnera probablement pendant des mois voire des années.
La seule chose que l'on peut regretter c'est le manque de doc officielle qui oblige à faire du reverse-engineering à chaque changement.
Tu as lu la conversation plus haut ? Si ce qui y est dit est vrai, ce n'est qu'une période transitoire suite à quoi le mot de passe sera vérifié, avec protection contre les rekeys, ce qui rend les routeurs alternatifs inutilisables. Pour moi ce n'est pas "pas grand chose", si ça se fait c'est une raison pour changer de FAI.
Le cas des américains est peut-être loin d'être exemplaire, en attendant chez eux tout est en DHCP et/ou avec un mode bridge sur un modem. Je ne vois pas pourquoi en France ça semble si dérangeant que ça que d'utiliser des standards correctement qui permettent l'interopérabilité.
-
Il n'a jamais été dit qu'il y aurait une protection contre les rejeu, ce sont de pures suppositions. Et quand bien même, un patch de 3 lignes dans dhclient et c'est réglé.
On est d'accord que l'idéal serait du DHCP "pur". Je critique simplement le fait que certains tirent des plans sur le comète en partant du principe qu'Orange fait la chasse aux routeurs alternatifs, et je doute franchement que ça soit le cas (ça serait se prendre la tête pour une poignée abonnés).
-
Moi on m'a parlé d'anti rejeu, on verra bien.
-
Si c'est bien le cas ils n'ont vraiment que ça à faire... ::)
-
Moi on m'a parlé d'anti rejeu, on verra bien.
plus de rumeur sans substance
-
Et ben... Je viendrais filer des infos plus souvent, ça fait plaisir :)
Le milieu des télécoms est un milieu très secret, et balancer des infos c'est déjà assez rare.
Amusez vous bien, je ne suis personnellement bientôt plus chez Orange, donc basta.
-
"que ça à faire" = implèmenter l'anti-rejeu, pas le fait de te donner des infos. :-*
-
Je pense à kgersen et à nivek.
-
déjà en cours
-
Il n'a jamais été dit qu'il y aurait une protection contre les rejeu, ce sont de pures suppositions.
Des quelques allégations de Hugues, c'est la plus crédible : avant même l'ajout des champs salt et MD5, juste avant le champ user, nous configurons tous nos clients DHCP pour envoyer 11 octets 0x00. Ces 11 octets 0x00 correspondent aux champs de replay detection de la RFC3118 (RD protocol, RD algorithm, RD method, RD value). En d'autres termes : la crédiblité de l'activation d'une protection contre le replay PRÉCÈDE de plusieurs mois (années ?) l'arrivée de ce champ MD5. Spécifiquement, je m'attends à ce que la Livebox se mette un jour à envoyer un timestamp au milieu de ces octets 0x00.
Et quand bien même, un patch de 3 lignes dans dhclient et c'est réglé.
Entièrement d'accord sur le principe (peut-être un peu plus que trois lignes mais je pinaille). Mais c'est plus facile à dire pour ceux d'entre nous qui avons des facilités pour personnaliser ce qui tourne sur nos équipements. Typiquement, pour une box Linux/BSD qui fait routeur, c'est très accessible. Mais beaucoup ici utilisent des routeurs plus génériques qui sont plus configurables qu'une Livebox mais moins souple qu'une box Linux/BSD.
On est d'accord que l'idéal serait du DHCP "pur".
Tout à fait. Ou sinon, une IP fixe, ça me va aussi, je ne suis pas difficile.
Je critique simplement le fait que certains tirent des plans sur le comète en partant du principe qu'Orange fait la chasse aux routeurs alternatifs, et je doute franchement que ça soit le cas (ça serait se prendre la tête pour une poignée abonnés).
Je ne pense pas non plus que les routeurs alternatifs soient la cible principale ; par contre, ils ne sont clairement qu'un à-côté dispensable, un détail, un vœu pieu face à la masse de LiveBox et aux roadmaps techniques internes. Je suppose également que le management Orange est réfractaire à publier des indications qui laisseraient à penser que le support Orange doive un jour fournir une assistance pour autre chose que la sacro-sainte Livebox (parce que ça compliquerait les choses, ça ferait baisser les stats de satisfaction de la hotline, etc.).
-
Des quelques allégations de Hugues, c'est la plus crédible
Et moi mon petit doigt m'a dit qu'il ne serait pas question d'anti rejeu mais uniquement de logging du challenge pour éventuellement détecter les usages anormaux. Et si anti rejeu il y a, ce ne sera pas basé sur la RFC mais du propriétaire orange.
-
T'entends quoi par usages anormaux ?
-
T'entends quoi par usages anormaux ?
Bah challenge toujours identique = pas une Livebox au bout, ce qui ne veut pas dire que ça entraînera un quelconque blocage.
-
Je suis en phase,
cependant, attention, j'ai remarqué un truc en testant chez moi.
La box génère un challenge unique à chaque reboot mais le réutilise ensuite pour la demande initiale mais également les refresh vers le serveur DHCP de mon edge router (en conf avec la box orange en DMZ).
Le challenge démarre actuellement systématiquement avec un compteur à 0 et je ne l'ai jamais vu s'incrèmenter pour le moment .
J'ai pu récupérer (via test avec le DHCP serveur et reboot auto en boucle de la box) quelques dizaines de token unique prêt à l'emploi.
Je pense que ceux-ci seront valables pour deux raisons:
- La livebox ne possède pas de batterie ou pile pour maintenir la clock interne , elle ne peut donc pas utiliser de timestamp à proprement parler dans la mesure qu'a chaque reboot cela part à zéro;
- La box ne sauvegarde pas aujourd'hui les baux entre deux reboot, cela n'est pas déconnant dans la mesure où cela pourrait générer des problèmes en cas de changements d'infra ou autre chez orange entre deux reboot;
La suite est de voir si il y a du changement dans la réponse officielle du serveur DHCP orange.Pour le moment ( avec les traces pcap en fond) rien n'a changé, pas d'incrèmentation sur les réponses.
Bah challenge toujours identique = pas une Livebox au bout, ce qui ne veut pas dire que ça entraînera un quelconque blocage.
-
Le challenge démarre actuellement systématiquement avec un compteur à 0 et je ne l'ai jamais vu s'incrèmenter pour le moment .
Par "compteur" tu veux dire quoi ? le RANDCHAR dans le post de Gucci gang ?
Parce que du coup ce n'est pas ce que je vois de mon coté, après reboot de ma Livebox lorsque j'ai voulu récupérer une option 90 complète, le RANDCHAR était à 0x66. Je n'ai pas regardé s'il change par contre.
-
Je ne pense pas non plus que les routeurs alternatifs soient la cible principale
J'en suis moins sur : Quel serait l'intérêt de complexifier cette procédure sinon ? Le protocole actuel (login + hash du password dans l'option 90 en statique) est largement suffisante. C'est pas solide certes (encore qu'ils pourraient utiliser un protocole de hash plus robuste), mais ça ne l'est pas davantage en PPP.
Je ne suis pas fan de la méthode Hugues ( "moi je sais des choses que vous savez pas, na na na") , mais il est logique que si il y a eu des changements, c'est pas pour rien, d'autant plus que les autres opérateurs n'ont pas ce genre de procédures.
Le mode bride a existé il y a très longtemps dans les livebox, il a été retiré. Pareil pour la possibilité de changer les DNS (et ce n'est que petite partie de ce qui est possible sur un routeur du commerce). Certes il y a un problème de maintenance / hotline / légal , mais à mon avis Orange va tout faire pour imposer ses livebox:
J'ai eu au téléphone des commerciaux d'OBS qui m'ont parlé de leurs "nouvelles" offres FTTH en marque blanche (Optimum ou un truc comme ça (*)) , et la réponse à ma question a été très très claire : C'est UNIQUEMENT des livebox, sans logo. Mais on sera limité aux livebox & leurs options. Quand je leur ai dit que moi je souhaitait placer mon propre matériel, ils ont immédiatement parlé d'offres plus importantes, genre FTTH collecté sur des portes CELAN (et là c'est plus du tout le même prix mensuel).
=> Donc à mon sens il y a une raison : Une certaine segmentation commerciale, avec en fond l'idée de ne "pas trop" laisser de possibilités aux offres les moins chères, de peur que les presta ouvrent des lignes FTTH (ou VDSL2) et placent leur offres par-dessus, avec des routeurs capable de faire du multiwan ou de la 4G pour éviter de prendre des liens avec GTR.
Surtout quand on prends en compte le fait que dans beaucoup de zones géographiques, pour avoir du VDSL2 ou du FTTH c'est Orange ou rien, les commerciaux d'OBS ne se sont pas gêné pour le rappeler (Ou SFR parfois, mais bon.... SFR quoi).
Je ne serais pas non plus étonné qu'Orange mette en place un "programme de certification" avec des routeurs tiers (payant pour les constructeurs) qui donneraient accès à ces derniers aux binaires d'Orange pour l'authentification, avec des contraintes sur les fonctionnalités (voire une redevance unitaire). Ce qui impliquerais, de fait, de garder secret l'algo pour éviter de le retrouver sous OpenWRT ou pfsense (pas mal utilisé chez les prestataires).
Ca se faisait , avant, pour les modems analogique même si c'était plutôt à l'époque pour la partie lien physique.
-
J'en suis moins sur : Quel serait l'intérêt de complexifier cette procédure sinon ?
La collecte et notamment l'auth est en pleine refonte. Et a l'échelle d'Orange et du nombre de ses abonnés c'est pas juste un dhcp dans un coin. Mais non, ce n'est pas pour empecher les routeurs tiers. Oui ça complique les choses, mais c'est pas non plus ouf. Perso j'ai beaucoup plus de soucis avec le dhcpv6 d'online que celui d'Orange par exemple.
Le protocole actuel (login + hash du password dans l'option 90 en statique) est largement suffisante.
Et est-ce qu'il y a besoin d'envoyer plus ? De ce que j'ai pu voir il n'y a pas encore besoin de plus que le fti et la chaine statique. Pas même le pass, même si les livebox l'envoient. Et si demain il faut envoyer le pass encodé avec un random a la xkcd (https://xkcd.com/221/), ben c'est pas bien compliqué.
Vous flippez tous sur le replay detection, et ok, je comprends. Mais rien ne dit que ça sera activé un jour. Et quand bien même ça serait activé, vu qu'ici en dhcp c'est le client qui envoie le secret, ben c'est pas bien solide comme mesure non plus.
Si Orange avait réellement voulu bloquer les routeurs tiers il y aurait eu un tunnel ipsec vers les serveurs d'auth par exemple. Comme ce que peut faire free entre player et server pour la tv...
-
La collecte et notamment l'auth est en pleine refonte. Et a l'échelle d'Orange et du nombre de ses abonnés c'est pas juste un dhcp dans un coin. Mais non, ce n'est pas pour empêcher les routeurs tiers. Oui ça complique les choses, mais c'est pas non plus ouf. Perso j'ai beaucoup plus de soucis avec le dhcpv6 d'online que celui d'Orange par exemple.
Et est-ce qu'il y a besoin d'envoyer plus ? De ce que j'ai pu voir il n'y a pas encore besoin de plus que le fti et la chaine statique. Pas même le pass, même si les livebox l'envoient. Et si demain il faut envoyer le pass encodé avec un random a la xkcd (https://xkcd.com/221/), ben c'est pas bien compliqué.
Effectivement, si ça reste comme c'est , ou similaire, alors oui OSEF.
(Et je suis d'accord avec la config de l'IPv6 par Free - j'ai jamais réussi à diffuser leur /60 dans mon LAN via la fbx crystal).
Vous flippez tous sur le replay detection, et ok, je comprends. Mais rien ne dit que ça sera activé un jour. Et quand bien même ça serait activé, vu qu'ici en dhcp c'est le client qui envoie le secret, ben c'est pas bien solide comme mesure non plus.
En fait ce sont les changements non documentés et non rfc-compliant, le problème, parce qu'a ce moment ça implique d'intervenir en urgence, et encore ce coup-là on avait de la chance, des gens ici ont réussi à trouver avant les modifs à faire.
(Ensuite, si c'est pas bien solide comme tu le dis, on se demande bien à quoi ça sert de le mettre en place. Est-ce que c'est pour éviter que des gens se connectent sur un arbre gpon sans abo en piquant le login fti/ du voisin ...? Mais dans ce cas, le problème est sur l'ONT, il me semble.... et ce problème doit déjà exister en ADSL / VDSL actuellement)
Si Orange avait réellement voulu bloquer les routeurs tiers il y aurait eu un tunnel ipsec vers les serveurs d'auth par exemple. Comme ce que peut faire free entre player et server pour la tv...
Mhhh dans ce cas il faudrait que la clé privée + certif client soit bien planqué dans le firmware. Mais oui, c'est certain.
-
Online, pas Free :-)
-
Idem.
D'ailleurs, en parlant de ça, je vois ce matin (mon premier RENEW a eu lieu hier soir, donc je ne sais pas si c'est lié à ça...) que je ne dépasse plus les 120 Mbits/sec. en débit descendant (Sur une offre Jet), aussi bien e IPv6 qu'en IPv4. J'ai par contre toujours les 300 Mbits/sec. montants... Je ne sais pas si c'est juste moi ou une nouvelle fourberie d'Orange (et malheureusement chez moi en FTTH c'est soit Orange soit rien).
testé avec iperf3
Bonjour
Je fonctionne dans configuration avec livebox pour le tel/tv et Erl 3 en DHCP avec br0/1 et ipv4 seulement. J'en suis à au moins 3 renew depuis le bound du 28/9/18 18h58, peut-être car mon router exécute le script watchdog de zoc? La chaine hexa send rfc3118-auth est toujours celle que j'ai copier dans les infos cachés de la livebox (livebox info onglet Mibs données DHCP V4 Sent option 90) pour avoir le bound. J'avais conservé la chaine complète et j'étais passé par l'interface Config Tree du router pour l'injecter (interfaces / ethernet / eth1 / vif / 832 / dhcp-options : DHCP client (IPv4) options ).
Pas de modification des débits (up 950 Mbps, down 300 Mbps en test rapide sur speedtest.net avec bouygues).
Il y a peut-être eu une déconnexion car le dernier renew est de ce matin à 1h00 alors que les premiers que j'ai constaté étaient toujours à 18h58.
Konki
-
=> Donc à mon sens il y a une raison : Une certaine segmentation commerciale, avec en fond l'idée de ne "pas trop" laisser de possibilités aux offres les moins chères, de peur que les presta ouvrent des lignes FTTH (ou VDSL2) et placent leur offres par-dessus, avec des routeurs capable de faire du multiwan ou de la 4G pour éviter de prendre des liens avec GTR.
Tout à fait d'accord, il y a, je pense, effectivement un enjeu commercial. Et l'industrialisation des déploiements quand on lance une nouvelle offre pro (ici sur le FTTH) devient un enjeu important. Si en plus cela fait taire les quelques geeks qui souhaitaient bypasser la livebox (là j'entends Orange glousser)...Donc à moins qu'Orange distingue les chaines de provisionning PRO/GP sur le FTTH, on devrait tous être soumis aux même règles, vous ne croyez pas ?
On devrait etre fixé prochainement (ou pas) de toute manière ;-)
-
Pour l'IPv6
c'est bien de
raw-option 11 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:65:77:74:FF:AB:XX:XX
à
raw-option 11 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:65:77:74:FF:AB:1a:09:00:00:05:58:01:03:41:01:0d:XX:XX
?
-
Pas de modification des débits (up 950 Mbps, down 300 Mbps en test rapide sur speedtest.net avec bouygues).
Fausse alerte chez moi, pour une raison qui m'échappe encore une VM ESXi qui atteignait le Gb depuis l'extérieur avant ne l'atteint plus, et de loin, sauf vers les autres machines de mon LAN (Pas le temps d'investiguer plus).
Par contre mon iMac tout neuf atteint bien le Gb depuis l'extérieur.
-
Pour l'IPv6
c'est bien de
raw-option 11 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:65:77:74:FF:AB:XX:XX
à
raw-option 11 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:65:77:74:FF:AB:1a:09:00:00:05:58:01:03:41:01:0d:XX:XX
Non.
La chaine pour l'option 11 est strictement identique à celle de l'option 90. Donc:
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
(suivi éventuellement du challenge + hash du mot de passe).
-
Et moi mon petit doigt m'a dit qu'il ne serait pas question d'anti rejeu mais uniquement de logging du challenge pour éventuellement détecter les usages anormaux. Et si anti rejeu il y a, ce ne sera pas basé sur la RFC mais du propriétaire orange.
Comme déjà dit, il y a plusieurs scénarios possibles ; celui que tu mentionnes me paraitrait assez inefficace de la part d'Orange parce que :
- de leur côté, ils devraient se faire ch*** à stocker/logger les challenges, avec toutes les contraintes qui vont avec ce genre de choses (surtout avec du stockage persistent en tête)
- de notre côté, à partir du moment où on doit calculer dynamiquement le contenu de l'option 90, que ce doit pour injecter le timestamp de la RFC 3118 ou pour générer aléatoirement un nouveau salt (à mon sens, on ne peut parler de challenge que s'il est fourni par le côté serveur) et hasher le mot de passe avec, ça ne change rien.
Bref, de mon côté, je vais prendre mes dispositions pour être en mesure de générer cette option 90 dynamiquement ; je ne sais pas si ça servira un jour, mais ça me fera une geekerie amusante en attendant :)
-
de mon côté, je vais prendre mes dispositions pour être en mesure de générer cette option 90 dynamiquement
;D ;D ;D ;D
-
=> Donc à mon sens il y a une raison : Une certaine segmentation commerciale, avec en fond l'idée de ne "pas trop" laisser de possibilités aux offres les moins chères, de peur que les presta ouvrent des lignes FTTH (ou VDSL2) et placent leur offres par-dessus, avec des routeurs capable de faire du multiwan ou de la 4G pour éviter de prendre des liens avec GTR.
+1
C'est le principe même du SD-WAN...
-
Wait'n see donc ;-)
Je fais parti de ceux qui doivent porter les IP publiques sur du matos dédiés, donc si Orange bloque ... Je partirais ^^
-
Wait'n see donc ;-)
Je fais parti de ceux qui doivent porter les IP publiques sur du matos dédiés, donc si Orange bloque ... Je partirai ^^
Oui, wait & see. Nous n'avons pas d'éléments nous prouvant formellement qu'Orange va empêcher la réutilisation effective d'un même salt. Peut-être qu'ils vont simplement les logger (par opposition à stocker), ça ne leur coûterait pas grand chose. Là tout de suite, il me paraît prématuré de changer de fournisseur d'accès juste pour ça.
-
Oui, wait & see. Nous n'avons pas d'éléments nous prouvant formellement qu'Orange va empêcher la réutilisation effective d'un même salt. Peut-être qu'ils vont simplement les logger (par opposition à stocker), ça ne leur coûterait pas grand chose. Là tout de suite, il me paraît prématuré de changer de fournisseur d'accès juste pour ça.
Ca depend. Ce coup ci on a eu de la chance car la modification ne nécessite pas de changement de code donc l'impact a été limité a quelques heures/jours.
La prochaine fois ca risque d'être différent et bien plus complexe voir impossible pour certains routeurs alternatifs.
Le souci c'est donc le downtime et les frais que ca risque de générer.
Et je vois mal Orange changer ses habitudes et prévenir a l'avance ses clients de la date et des détails...
Franchement vu la tournure que ca prend la sagesse pour ceux qui ne veulent prendre aucun risque est d 'aller chez un autre opérateur si c'est possible.
Ceux qui restent ou n'ont pas le choix d'un autre opérateur devraient préparer un plan B de leur config ou prévoir rapidement de changer leur routeur alternatif pour un équipement dont on peut rapidement modifier le code du client dhcp...
-
Franchement vu la tournure que ca prend la sagesse pour ceux qui ne veulent prendre aucun risque est d 'aller chez un autre opérateur si c'est possible.
Le problème est toujours le même - lorsque le but est de bénéficier du plus de débit possible (quel qu’en soit la raison), bahh bien souvent Orange est le seul FAI dispo.
En FTTH la promesse de la mutualisation se concrétise parfois après des années, et en VDSL2 , surtout en MED campagnarde, ben c'est même pas une possibilité, les autres FAI restent en ADSL 1Mbps, ils équipent pas les armoires de rues. Déjà que bien souvent ils sont même pas présent au NRA de rattachement...
Quand tu entends le *maire* lui-même au moment de l'inauguration faire l'éloge de "France Télécom" et expliquer à ses administrés qu'il faut s'abonner chez Orange pour les "remercier" d'avoir pris en charge le "THD" (oubliant qu'il a été financé par le conseil régional).... La comm' institutionnelle marche bien :-)
-
hors sujet complet là ...
-
Ca depend. Ce coup ci on a eu de la chance car la modification ne nécessite pas de changement de code donc l'impact a été limité a quelques heures/jours.
La prochaine fois ca risque d'être différent et bien plus complexe voir impossible pour certains routeurs alternatifs.
Le souci c'est donc le downtime et les frais que ca risque de générer.
Et je vois mal Orange changer ses habitudes et prévenir a l'avance ses clients de la date et des détails...
Franchement vu la tournure que ca prend la sagesse pour ceux qui ne veulent prendre aucun risque est d 'aller chez un autre opérateur si c'est possible.
Ceux qui restent ou n'ont pas le choix d'un autre opérateur devraient préparer un plan B de leur config ou prévoir rapidement de changer leur routeur alternatif pour un équipement dont on peut rapidement modifier le code du client dhcp...
C'est pour ça que je n'ai pas qu'une seule connexion (porte de sortie), mais 2.
Je suis MultiHomé , j'ai Orange en principal, et SFR qui prend le relai si l'IP Orange monte plus. J'aurai donc pas de downtime, et largement le temps de penser à changer de FAI "principal" , le jour où je serai bloqué (j'ai toujours mon secondaire dand tous les cas).
C'est d'ailleurs aussi un des interêts d'avoir son propre matos : on peut s'abonner à X fournisseurs , et s'amuser à sortir depuis tel ou tel AS selon où l'on va , etc... bref , je suis pas inquiet ni géné plus que ça ;-)
-
c'est bien beau tout ça ;D
mais à part ça, est-ce que quelqu'un connait un client dhcp unix léger permettqnt de hooker un script au moment de la réception du challenge dhcp, permettant de récupérer les paramètres du challenge, et d'altérer les options renseignées dans la réponse?
j'ai étudié le cas du ISC dhclient, il permet de hooker des scripts, mais pas entre la requete et la réponse... le code C est dégueu donc j'hésite à me lancer dans la création d'un patch pour permettre ce que j'évoque plus haut. Au temps utiliser un truc plus moderne, mais j'ai rien trouvé pour l'instant.
-
Pour linux, a part le client DHCP ISC, il existe celui de busybox (https://git.busybox.net/busybox/tree/networking/udhcp/dhcpc.c).
Sinon, Haiku a sa propre implèmentation (https://git.haiku-os.org/haiku/tree/src/servers/net/DHCPClient.cpp).
-
j'ai étudié le cas du ISC dhclient, il permet de hooker des scripts, mais pas entre la requete et la réponse... le code C est dégueu donc j'hésite à me lancer dans la création d'un patch pour permettre ce que j'évoque plus haut.
Je vais m'y coller dans les prochains jours ; spécifiquement, je pense introduire un mot-clé à la execute() mais qui retournerait la stdout du processus forké (idéalement de manière à ce qu'on puisse combiner la chaîne ainsi obtenue à des fonctions comme concat() et cie). À mon sens, le plus chiant, c'est de bien comprendre comment les différentes structures (universe, option_state, option_cache, expression, data_string) s'imbriquent les unes avec les autres.
-
Le code d'ISC DHCP est moins compliqué qu'il n'y parait. J'avais commencé à faire un patch plus gérer la priorité de manière plus propre que pour mon premier patch (où la prio à 6 est en dur), et j'avais rajouté une optio "prio" dans le fichier de config. Faute de temps je ne suis pas allé au bout, mais en pratique rien d'insurmontable...
L'idée de rajouter un "execute" pour une option est à mon avis excellente !
-
Bonjour à tous,
Je viens de passer de pfSense 2.3.1 à la 2.4.4, suite a la fin du BAIL dhcp( ayant l'ancienne option 77).
J'ai bien réussi avoir le net sur le vlan 832 et la tv mais ma connexion est bridée.
Avec la livebox je suis à 900Mbps en DL et 300 en UP mais avec le pfSsence j'ai 600Mbps en DL et seulement 4.80Mmps en UP !
Auriez vous une idée ?
Autre question :
j'ai fait un dump de l'option 77 sur la livebox et la chaine que j'ai est bien plus longue que celle que j'utilise à savoir celle donnée dans d'autres poste du forum.
Merci par avance.
-
Hello,
Es-tu seulement sûr que ta box pfSense est capable de router à 900 Mbps ? Le routage logiciel demande un minimum de puissance brute, ce n'est pas donné à tous les matériels et routeurs grand public.
Pour l'option 77, le mieux est de prendre celle que ta Livebox te fournit, si tu suis les posts précédents tu verras que ce que tu as pris n'inclut pas ton mot de passe (qui n'est pas vérifié à l'heure actuelle), alors que ta Livebox le fournit.
-
Mon routeur avec pfSense 2.3.1 me permettait d'avoir les même débit que la livebox. La bride n'est pas hardware.
Quand je mets l'option capturée sur le livebox en entier j'ai ça dans le log pfSence du DHCP :
unknown dhcp option value 0x5a
unknown dhcp option value 0x78
unknown dhcp option value 0x7d
mais j'ai quand même le net.
Un autre idée sur le pouruqoi je suis bridé ? A mon avis c'est problème de configuration du pfSence. Est ce que ça peut venir du firewall ou du NAT ?
-
Depuis le renew du bail DHCP, je suis aussi passé à 700Mbps, donc ça vient sans doute d'Orange.
J'ai lu plus haut que des reboots ONT amélioraient la situation. Je testerai un reboot de tout le stack réseau un peu plus tard (je n'ai pas d'ONT, SFP direct sur un switch Mikrotik perso), on verra si ça change quelque chose.
-
Je viens de rebooter l'ONT mais ça ne change rien :(
-
Je viens de passer de pfSense 2.3.1 à la 2.4.4, suite a la fin du BAIL dhcp( ayant l'ancienne option 77).
J'ai bien réussi avoir le net sur le vlan 832 et la tv mais ma connexion est bridée.
Avec la livebox je suis à 900Mbps en DL et 300 en UP mais avec le pfSsence j'ai 600Mbps en DL et seulement 4.80Mmps en UP !
C'est la 90 qui a changé à ce jour, pas la 77. L'upgrade du routeur est peut-être en cause ?
-
Je vais m'y coller dans les prochains jours ; spécifiquement, je pense introduire un mot-clé à la execute() mais qui retournerait la stdout du processus forké (idéalement de manière à ce qu'on puisse combiner la chaîne ainsi obtenue à des fonctions comme concat() et cie).
Quelques nouvelles : j'ai sous les yeux un début de patch pour isc-dhcp 4.3.5 (tel que packagé sous Debian Stretch) qui me permet de déléguer la génération de l'option 90 à un exécutable externe (par exemple un script Python) avec la syntaxe suivante :
option authentication code 90 = string;
send authentication = generate("/etc/orange/auth");
C'est encore très frais, il y a pas mal de choses à peaufiner (gestion d'erreur, tests poussés, etc.) mais je pense avoir déjà fait le plus gros. Je vous partage ça dès que c'est présentable.
-
svp quelqu'un pourrait-il poster une capture des 4 paquets DHCP échangés entre la Livebox et Orange svp?
a l'instar de ce que j'avait fait pour l'ancienne méthode: https://lafibre.info/remplacer-livebox/remplacer-la-livebox-sans-pppoe/msg320002/#msg320002
-
svp quelqu'un pourrait-il poster une capture des 4 paquets DHCP échangés entre la Livebox et Orange svp?
a l'instar de ce que j'avait fait pour l'ancienne méthode: https://lafibre.info/remplacer-livebox/remplacer-la-livebox-sans-pppoe/msg320002/#msg320002
DHCP Discover (Livebox -> Orange, vlan 832, CoS 6)
Frame 47: 438 bytes on wire (3504 bits), 438 bytes captured (3504 bits)
Ethernet II, Src: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x67225d47
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (55) Parameter Request List
Length: 12
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (51) IP Address Lease Time
Parameter Request List Item: (58) Renewal Time Value
Parameter Request List Item: (59) Rebinding Time Value
Parameter Request List Item: (90) Authentication
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (120) SIP Servers
Parameter Request List Item: (125) V-I Vendor-specific Information
Option: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0)
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
User Class Length: 43
User Class Data: 46535644534c5f6c697665626f782e496e7465726e65742e...
Option: (90) Authentication
Length: 70
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: \032\t
Option: (255) End
Option End: 255
DHCP Offer (Orange -> Livebox, vlan 832, CoS 7)
Frame 48: 481 bytes on wire (3848 bits), 481 bytes captured (3848 bits)
Ethernet II, Src: Nokia_ef:70:f9 (84:26:2b:ef:70:f9), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 7, DEI: 0, ID: 832
Internet Protocol Version 4, Src: 90.127.124.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x67225d47
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 90.127.125.XX
Next server IP address: 80.10.247.48
Relay agent IP address: 80.10.236.81
Client MAC address: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 80.10.247.48
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (259200s) 3 days
Option: (119) Domain Search
Length: 34
FQDN: PUT.access.orange-multimedia.net
Option: (1) Subnet Mask
Length: 4
Subnet Mask: 255.255.254.0
Option: (3) Router
Length: 4
Router: 90.127.124.1
Option: (6) Domain Name Server
Length: 8
Domain Name Server: 80.10.246.136
Domain Name Server: 81.253.149.6
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (207400s) 2 days, 9 hours, 36 minutes, 40 seconds
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (88190s) 1 day, 29 minutes, 50 seconds
Option: (125) V-I Vendor-specific Information
Length: 17
Enterprise: Orange (formerly 'France Telecom') (1368)
Length: 12
Option 125 Suboption: 1
Option: (28) Broadcast Address
Length: 4
Broadcast Address: 90.127.125.255
Option: (120) SIP Servers
Length: 42
SIP Server Encoding: Fully Qualified Domain Name (0)
SIP Server Name: sbct3g.PUT.access.orange-multimedia.net
Option: (90) Authentication
Length: 27
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: dhcpliveboxfr250
Option: (15) Domain Name
Length: 9
Domain Name: orange.fr
Option: (255) End
Option End: 255
DHCP Request (Livebox -> Orange, vlan 832, CoS 6)
Frame 49: 450 bytes on wire (3600 bits), 450 bytes captured (3600 bits)
Ethernet II, Src: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Bootstrap Protocol (Request)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x67225d47
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 90.127.125.62
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 80.10.247.48
Option: (55) Parameter Request List
Length: 12
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (51) IP Address Lease Time
Parameter Request List Item: (58) Renewal Time Value
Parameter Request List Item: (59) Rebinding Time Value
Parameter Request List Item: (90) Authentication
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (120) SIP Servers
Parameter Request List Item: (125) V-I Vendor-specific Information
Option: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0)
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
User Class Length: 43
User Class Data: 46535644534c5f6c697665626f782e496e7465726e65742e...
Option: (90) Authentication
Length: 70
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: \032\t
Option: (255) End
Option End: 255
DHCP ACK (Orange -> Livebox, vlan 832, CoS 7)
Frame 50: 481 bytes on wire (3848 bits), 481 bytes captured (3848 bits)
Ethernet II, Src: Nokia_ef:70:f9 (84:26:2b:ef:70:f9), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 7, DEI: 0, ID: 832
Internet Protocol Version 4, Src: 90.127.124.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Bootstrap Protocol (ACK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x67225d47
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 90.127.125.62
Next server IP address: 80.10.247.48
Relay agent IP address: 80.10.236.81
Client MAC address: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (ACK)
Length: 1
DHCP: ACK (5)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 80.10.247.48
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (259200s) 3 days
Option: (119) Domain Search
Length: 34
FQDN: PUT.access.orange-multimedia.net
Option: (1) Subnet Mask
Length: 4
Subnet Mask: 255.255.254.0
Option: (3) Router
Length: 4
Router: 90.127.124.1
Option: (6) Domain Name Server
Length: 8
Domain Name Server: 80.10.246.136
Domain Name Server: 81.253.149.6
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (207400s) 2 days, 9 hours, 36 minutes, 40 seconds
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (89036s) 1 day, 43 minutes, 56 seconds
Option: (125) V-I Vendor-specific Information
Length: 17
Enterprise: Orange (formerly 'France Telecom') (1368)
Length: 12
Option 125 Suboption: 1
Option: (28) Broadcast Address
Length: 4
Broadcast Address: 90.127.125.255
Option: (120) SIP Servers
Length: 42
SIP Server Encoding: Fully Qualified Domain Name (0)
SIP Server Name: sbct3g.PUT.access.orange-multimedia.net
Option: (90) Authentication
Length: 27
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: dhcpliveboxfr250
Option: (15) Domain Name
Length: 9
Domain Name: orange.fr
Option: (255) End
Option End: 255
-
Option: (90) Authentication
Length: 70
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: \032\t
Ah, perdu : ce que tu as utilisé pour afficher ta capture a décidé de s'arrêter au premier octet nul après 0x1A 0x09... tu dois avoir une option pour fournir un dump hexadécimal (qu'il te faudra alors anonymiser).
Sauf erreur de ma part, ça devrait donner un truc comme ça :
00000000 00 00 00 00 00 00 00 00 00 00 00 1a 09 00 00 05 |................|
00000010 58 01 03 41 01 0d 66 74 69 2f 61 62 63 64 31 32 |X..A..fti/abcd12|
00000020 33 3c 12 53 41 4c 54 73 61 6c 74 53 41 4c 54 73 |3<.SALTsaltSALTs|
00000030 61 6c 74 03 13 42 c4 47 95 47 7b 2a ac 7b 6e 72 |alt..B.G.G{*.{nr|
00000040 21 ae 0f 3f 35 cc |!..?5.|
-
C'est la 90 qui a changé à ce jour, pas la 77. L'upgrade du routeur est peut-être en cause ?
Effectivement je me suis trompé je parlais bien de l'option 90 et non 77, désolé.
En effet c'est peut être l'upgrade en 2.4.4 quelqu'un a t'il testé la 2.4.4 ?
Merci par avance c'est très problématique de ne plus avoir d'upload :(
-
Sauf erreur de ma part, ça devrait donner un truc comme ça :...
Voici le dump anonimizé :
0000 5a 46 00 00 00 00 00 00 00 00 00 00 00 1a 09 00 ZF..............
0010 00 05 58 01 03 41 01 0d 66 74 69 2f 7a 78 75 41 ..X..A..fti/zxuA
0020 41 41 41 3c 12 42 52 2e 72 3d 6e 3d 3c 33 46 40 AAA<.BR.r=n=<3F@
0030 74 2c 35 55 5a 03 13 36 a4 0f 72 c1 30 12 25 5e t,5UZ..6..r.0.%^
0040 f3 38 37 14 9a be 0b eb .87.....
-
Voici le dump anonimizé :
Ah oui, bien vu, avec le code de l'option et la longueur du champ, ça ne fait pas de mal.
J'en profite pour ajouter une question à tous ceux qui s'amusent encore à sniffer le trafic de leur LiveBox : est-ce que le salt est toujours composé de caractères ASCII ou est-ce qu'il peut contenir autre chose ? Aujourd'hui, je génère un salt binaire (ça me semble l'approche normale) mais je me demande s'il ne faudrait pas se cantonner aux caractères imprimables de la table ASCII...
-
ok merci pour les captures. C'est bien exactement la meme valeur qui est envoyée par le DISCOVER et le REQUEST donc ?
La livebox n'utilise donc pas (a ce jour) de valeur(s) recue(s) dans le OFFER pour modifier son authentification. Elle est purement autonome donc.
-
ok merci pour les captures. C'est bien exactement la meme valeur qui est envoyée par le DISCOVER et le REQUEST donc ?
La livebox n'utilise donc pas (a ce jour) de valeur(s) recue(s) dans le OFFER pour modifier son authentification. Elle est purement autonome donc.
Oui, c'est bien la même valeur dans l'option 90 (dumps anonimizés):
DISCOVER
0000 5a 46 00 00 00 00 00 00 00 00 00 00 00 1a 09 00 ZF..............
0010 00 05 58 01 03 41 01 0d 66 74 69 2f 7a 78 75 41 ..X..A..fti/zxuA
0020 41 41 41 3c 12 42 52 2e 72 3d 6e 3d 3c 33 46 40 AAA<.BR.r=n=<3F@
0030 74 2c 35 55 5a 03 13 36 a4 0f 72 c1 30 12 25 5e t,5UZ..6..r.0.%^
0040 f3 38 37 14 9a be 0b eb .87.....
REQUEST
0000 5a 46 00 00 00 00 00 00 00 00 00 00 00 1a 09 00 ZF..............
0010 00 05 58 01 03 41 01 0d 66 74 69 2f 7a 78 75 41 ..X..A..fti/zxuA
0020 41 41 41 3c 12 42 52 2e 72 3d 6e 3d 3c 33 46 40 AAA<.BR.r=n=<3F@
0030 74 2c 35 55 5a 03 13 36 a4 0f 72 c1 30 12 25 5e t,5UZ..6..r.0.%^
0040 f3 38 37 14 9a be 0b eb .87.....
Je peux fournir le fichier pcap complet par PM.
Dans l'OFFER:
Frame 48: 481 bytes on wire (3848 bits), 481 bytes captured (3848 bits)
Ethernet II, Src: Nokia_ef:70:f9 (84:26:2b:ef:70:f9), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 7, DEI: 0, ID: 832
Internet Protocol Version 4, Src: 90.127.124.1, Dst: 255.255.255.255
User Datagram Protocol, Src Port: 67, Dst Port: 68
Source Port: 67
Destination Port: 68
Length: 443
Checksum: 0x28d0 [unverified]
[Checksum Status: Unverified]
[Stream index: 5]
Bootstrap Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x67225d47
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 90.127.125.XX
Next server IP address: 80.10.247.48
Relay agent IP address: 80.10.236.81
Client MAC address: 70:0b:01:b3:ae:b0 (70:0b:01:b3:ae:b0)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 80.10.247.48
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (259200s) 3 days
Option: (119) Domain Search
Length: 34
FQDN: PUT.access.orange-multimedia.net
Option: (1) Subnet Mask
Length: 4
Subnet Mask: 255.255.254.0
Option: (3) Router
Length: 4
Router: 90.127.124.1
Option: (6) Domain Name Server
Length: 8
Domain Name Server: 80.10.246.136
Domain Name Server: 81.253.149.6
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (207400s) 2 days, 9 hours, 36 minutes, 40 seconds
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (88190s) 1 day, 29 minutes, 50 seconds
Option: (125) V-I Vendor-specific Information
Length: 17
Enterprise: Orange (formerly 'France Telecom') (1368)
Length: 12
Option 125 Suboption: 1
Option: (28) Broadcast Address
Length: 4
Broadcast Address: 90.127.125.255
Option: (120) SIP Servers
Length: 42
SIP Server Encoding: Fully Qualified Domain Name (0)
SIP Server Name: sbct3g.PUT.access.orange-multimedia.net
Option: (90) Authentication
Length: 27
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: dhcpliveboxfr250
Option: (15) Domain Name
Length: 9
Domain Name: orange.fr
Option: (255) End
Option End: 255
Option 90 dans le packet DHCP offer:
0000 5a 1b 00 00 00 00 00 00 00 00 00 00 00 64 68 63 Z............dhc
0010 70 6c 69 76 65 62 6f 78 66 72 32 35 30 pliveboxfr250
La valeur "dhcpliveboxfr250" n'est pas utilisée.
-
Je viens de passer de pfSense 2.3.1 à la 2.4.4, suite a la fin du BAIL dhcp( ayant l'ancienne option 77).
J'ai bien réussi avoir le net sur le vlan 832 et la tv mais ma connexion est bridée.
Avec la livebox je suis à 900Mbps en DL et 300 en UP mais avec le pfSsence j'ai 600Mbps en DL et seulement 4.80Mmps en UP !
Auriez vous une idée ?
Effectivement je me suis trompé je parlais bien de l'option 90 et non 77, désolé.
En effet c'est peut être l'upgrade en 2.4.4 quelqu'un a t'il testé la 2.4.4 ?
Merci par avance c'est très problématique de ne plus avoir d'upload :(
Une idée pour moi ? please :-[
-
Je viens de passer de pfSense 2.3.1 à la 2.4.4, suite a la fin du BAIL dhcp( ayant l'ancienne option 77).
J'ai bien réussi avoir le net sur le vlan 832 et la tv mais ma connexion est bridée.
Avec la livebox je suis à 900Mbps en DL et 300 en UP mais avec le pfSsence j'ai 600Mbps en DL et seulement 4.80Mmps en UP !
Auriez vous une idée ?
Une idée pour moi ? please :-[
Cela semble plutôt un problème avec pfSense. Tu peux refaire tourner le wizard "traffic shaper" pour t'assurer que la configuration QoS soit adaptée à ta nouvelle version ? Sinon, tu peux downgrader à la version 2.3.1 et reesayer ?
Jusqu'à maintenant, le changement de l'option 90 ne fait que donner accès au réseau. Pas de bridage de débit en fonction de la chaine envoyé par le client DHCP. Du coup, il est probable que le problème soit avec ta configuration, soit avec l'infrastructure Orange (mais comme ta LB fonctionne bien, c'est probablèment à écarter).
-
Cela semble plutôt un problème avec pfSense. Tu peux refaire tourner le wizard "traffic shaper" pour t'assurer que la configuration QoS soit adaptée à ta nouvelle version ? Sinon, tu peux downgrader à la version 2.3.1 et reesayer ?
Jusqu'à maintenant, le changement de l'option 90 ne fait que donner accès au réseau. Pas de bridage de débit en fonction de la chaine envoyé par le client DHCP. Du coup, il est probable que le problème soit avec ta configuration, soit avec l'infrastructure Orange (mais comme ta LB fonctionne bien, c'est probablèment à écarter).
Je viens de faire un wizard du trafic shaper en laissant tout par default mais ça ne résout pas mon problème.
J'ai également essayé de reloader l'image de mon pfSense 2.33 mais malheureusement je n'arrive pas à la faire remarcher.
Voici un log de mon outboud nat est ce qu'il y a des choses à changer ou ajouter ?
est ce que ça peut venir du fait que AES-NI CPU Crypto: No ? (J'ai lu qu'a partir d'une certaine version pfSense ne supportait plus le AES-NI ?)
-
J'en profite pour ajouter une question à tous ceux qui s'amusent encore à sniffer le trafic de leur LiveBox : est-ce que le salt est toujours composé de caractères ASCII ou est-ce qu'il peut contenir autre chose ? Aujourd'hui, je génère un salt binaire (ça me semble l'approche normale) mais je me demande s'il ne faudrait pas se cantonner aux caractères imprimables de la table ASCII...
Basé sur 4 captures, pour l'instant j'en déduit que c'est toujours des caractères imprimables:
String: []^#!-(){},`;:&*abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ012345789
Char: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ012345789
-
Basé sur 4 captures, pour l'instant j'en déduit que c'est toujours des caractères imprimables:
String: []^#!-(){},`;:&*abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ012345789
Char: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ012345789
Merci pour le feedback :)
-
Pour les plus courageux, preview (https://xavier.kindwolf.org/2018-orange-dhcp/) de mon patch isc-dhcp-client :
- isc-dhcp-generate.diff (https://xavier.kindwolf.org/2018-orange-dhcp/isc-dhcp-generate.diff) : le patch lui-même
- MANIFEST (https://xavier.kindwolf.org/2018-orange-dhcp/MANIFEST) : détails sur les fichiers fournis
- auth (https://xavier.kindwolf.org/2018-orange-dhcp/auth) : un script Python 3 pour générer l'option 90/11
- credentials (https://xavier.kindwolf.org/2018-orange-dhcp/credentials) : pour stocker vos credentials dans un fichier à part
-
Je suis tout seul dans ce thread maintenant ?
Plus sérieusement, les fichiers mentionnés ci-dessus ont été mis à jour : la partie Python n'a pas bougé d'un octet mais le patch pour isc-dhcp est à mon sens terminé. J'ai également amélioré les instructions Debian-specific dans le fichier MANIFEST.
Prochaine étape pour moi : soumettre le patch à l'ISC pour une éventuelle intégration.
-
Bonjour à tous,
Je viens de passer de pfSense 2.3.1 à la 2.4.4, suite a la fin du BAIL dhcp( ayant l'ancienne option 77).
J'ai bien réussi avoir le net sur le vlan 832 et la tv mais ma connexion est bridée.
Avec la livebox je suis à 900Mbps en DL et 300 en UP mais avec le pfSsence j'ai 600Mbps en DL et seulement 4.80Mmps en UP !
Auriez vous une idée ?
Autre question :
j'ai fait un dump de l'option 77 sur la livebox et la chaine que j'ai est bien plus longue que celle que j'utilise à savoir celle donnée dans d'autres poste du forum.
Merci par avance.
Bonjour,
Depuis le changement de la chaine d'authentification de l'option 90, j'ai environ 3 mbit/s mais uniquement sur le vlan que j'ai dédié à la livebox (ma livebox est derriere le pfsense) et j'ai ce débit sur le wifi de la livebox, j'ai 2 autres vlan et le débit est normal dessus. Peut être est ce le même problème ? J'hésite à mettre à jour pfsense du coup si l'upload sur tous mes vlans passe de 300 mbit/s à 3 mbit/s :-\ . Des nouvelles infos sur ce problème ?
Merci
-
Je suis tout seul dans ce thread maintenant ?
Plus sérieusement, les fichiers mentionnés ci-dessus ont été mis à jour : la partie Python n'a pas bougé d'un octet mais le patch pour isc-dhcp est à mon sens terminé. J'ai également amélioré les instructions Debian-specific dans le fichier MANIFEST.
Prochaine étape pour moi : soumettre le patch à l'ISC pour une éventuelle intégration.
Je travaille avec OPNsense sur une solution similaire pour le client dhclient et dhcp6c sous FreeBSD. Attendez-vous à une mise à jour sur les progrès dans les prochaines semaines
-
Je suis tout seul dans ce thread maintenant ?
sans doute un souci de 'clientele' et de timing:
la plupart des utilisateurs ici sont incapables de patcher eux-meme avec ton diff et surtout tres peu utilisent isc-dhcp.
Ceux qui ont les compétences attendent surtout la prochaine modif d'Orange avant de faire quoi que ce soit.
-
sans doute un souci de 'clientele' et de timing:
la plupart des utilisateurs ici sont incapables de patcher eux-meme avec ton diff et surtout tres peu utilisent isc-dhcp.
Ceux qui ont les compétences attendent surtout la prochaine modif d'Orange avant de faire quoi que ce soit.
Exactement... Wait and see.
J'ai tout préparé au maximum pour la generation.
Pour ma part j'utilise udhcpc de busybox sur ddwrt et j'ai juste prevu une sorte de commande wrapper qui redémarre la vrai commande udhcpc avec une nouvelle generation de random string et char lorsque la negociation echoue.
Mais tout ca ne peut pas etre mis en place tant qu'on ne sait pas si les chaines d'auth que l'on generent sont valide ou pas car pour l'instant orange accepte tout...
-
sans doute un souci de 'clientele' et de timing:
la plupart des utilisateurs ici sont incapables de patcher eux-meme avec ton diff et surtout tres peu utilisent isc-dhcp.
Ceux qui ont les compétences attendent surtout la prochaine modif d'Orange avant de faire quoi que ce soit.
Tous les possesseurs ERL utilisent isc-dhcp :) bon ok c'est pas la même version et le patch ne s'applique pas mais c'est un bon point de départ!
Si j'arrive a prendre un peu de temps je regarderais pour adapter ça ce week-end
-
Pour ma part je préfère attendre les prochaines modif d'Orange pour voir comment ça évolue... Mais sinon le principle avec isc-dhcp me paraît pas mal...
-
sans doute un souci de 'clientele' et de timing: [...]
Oui, je me doute bien, je disais ça pour taquiner :)
Tous les possesseurs ERL utilisent isc-dhcp :) bon ok c'est pas la même version et le patch ne s'applique pas mais c'est un bon point de départ!
Si j'arrive a prendre un peu de temps je regarderais pour adapter ça ce week-end
Ah, intéressant -- c'est quelle version (exacte si possible) d'isc-dhcp sous ERL ?
-
Oui, je me doute bien, je disais ça pour taquiner :)
Ah, intéressant -- c'est quelle version (exacte si possible) d'isc-dhcp sous ERL ?
Il me semble que c'est la version 4.3.3 mais à vérifier
-
Oui, je me doute bien, je disais ça pour taquiner :)
Ah, intéressant -- c'est quelle version (exacte si possible) d'isc-dhcp sous ERL ?
C'est la version 4.1-ESV-R8 ... mais visiblement modifiée ...
Le tarball complet des sources peut être récupéré ici: https://www.ubnt.com/download/edgemax/edgerouter-lite/erlite3/edgerouter-erlite-3erpoe-5-firmware-v1105
=> source/vyatta-dhcp3_4.1-ESV-R8-ubnt2+t5127967-dev-v1.10.7-e1137c3.tgz
-
Effectivement, le patch s'applique correctement sur une 4.3.3 mais pas sur une 4.1-ESV-R8... je vais regarder si le rétroportage est faisable...
Edit 1: je viens de m'apercevoir que, contrairement à mes dires, je n'avais pas uploadé le dernier patch... c'est du propre... C'est désormais corrigé.
Edit 2: le patch ne s'appliquait pas sur une 4.1-ESV-R8 uniquement à cause de différences de contexte que j'ai pu ajuster rapidement ; voici donc une variante du patch pour le tag v4_1_esv_r8 tel qu'on le trouve dans le dépôt officiel : https://xavier.kindwolf.org/2018-orange-dhcp/isc-dchp-generate-for-tag-v4_1_esv_r8.diff
Limitations :
- je n'ai pas testé si ça compile
- le patch s'applique presque sans problème sur la version modifiée d'ERL : il y a juste le fichier config.h.in qui n'est pas présent :
erl/source $ curl -s https://xavier.kindwolf.org/2018-orange-dhcp/isc-dchp-generate-for-tag-v4_1_esv_r8.diff | patch -p 1 --dry-run
checking file common/conflex.c
checking file common/dhcp-eval.5
checking file common/parse.c
checking file common/print.c
checking file common/tree.c
checking file configure.ac
can't find file to patch at input line 407
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/includes/config.h.in b/includes/config.h.in
|index a762e51f..a0523813 100644
|--- a/includes/config.h.in
|+++ b/includes/config.h.in
--------------------------
File to patch:
Skip this patch? [y] y
Skipping patch.
1 out of 1 hunk ignored
checking file includes/dhctoken.h
checking file includes/site.h
checking file includes/tree.h
-
Ubiquiti est en Alpha3 sur la version 2.0.0 avec une upgrade de la base debian (Jessie -> Stretch).
Mais la dernière version de vyatta-dhcp3 est toujours en 4.1-ESV-R8 (https://github.com/vyos/vyatta-dhcp3).
Cela vaudrait le coup d'envoyé un PR sur le repositery vyos vu que c'est désormais l'upstream.
-
Ici je suis sur du Mikrotik / RouterOS, donc je l'ai un peu profond si ça change encore :o
-
Ubiquiti est en Alpha3 sur la version 2.0.0 avec une upgrade de la base debian (Jessie -> Stretch).
Mais la dernière version de vyatta-dhcp3 est toujours en 4.1-ESV-R8 (https://github.com/vyos/vyatta-dhcp3).
Cela vaudrait le coup d'envoyé un PR sur le repositery vyos vu que c'est désormais l'upstream.
Pourquoi pas, oui -- dans un premier temps, je vais attendre le feedback de l'ISC sur le patch (ça risque de prendre un peu de temps par contre) : https://bugs.isc.org/Public/Bug/Display.html?id=48316
-
Pourquoi pas, oui -- dans un premier temps, je vais attendre le feedback de l'ISC sur le patch (ça risque de prendre un peu de temps par contre) : https://bugs.isc.org/Public/Bug/Display.html?id=48316
Merci pour ton aide ;)
-
Vous avez une idée si on peut faire un truc similaire avec dibbler pour l’IPv6 ?
De ce que je vois d’ici, on peut utiliser 'auth-protocol reconfigure-key' et 'auth-methods digest-hmac-md5' mais je ne sais pas si ça suffit, je ne suis pas assez calé en DHCPv6 :D
-
Vous avez une idée si on peut faire un truc similaire avec dibbler pour l’IPv6 ?
De ce que je vois d’ici, on peut utiliser 'auth-protocol reconfigure-key' et 'auth-methods digest-hmac-md5' mais je ne sais pas si ça suffit, je ne suis pas assez calé en DHCPv6 :D
Mes impressions à la lecture (en diagonale) de http://klub.com.pl/dhcpv6/doc/dibbler-user.pdf :
- Dibbler n'offre pas de fonctionnalité équivalente à l'opérateur generate() que j'ai implèmenté
- Dibbler supporte pas mal de variantes d'authentification over DHCP mais j'ai le sentiment qu'il ne supporte aucune variante aussi stupide que celle implèmentée par Orange -- un expert Dibbler pour confirmer ?
-
Bon, sinon, même si ce n'est pas vraiment lié à l'option 90, une nouvelle petite surprise coté décodeur TV5 (et je ne vois pas pourquoi ça ne serait pas porté tôt ou tard sur les anciens décodeurs): Quand ils sont utilisés derrière un routeur tiers directement, alors le serveur DHCP de ce routeur doit envoyer l'option 125 en respectant le format décrit ici:
https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/msg583625/#msg583625
-
le serveur DHCP de ce routeur doit envoyer l'option 125 en respectant le format [décrit ici]
Je profite de cette perche pour signaler que la fonctionnalité generate() implèmentée dans le cadre de nos petites orangeries n'est pas spécifique au client ISC dhclient : elle est également disponible pour le serveur ISC dhcpd. Cela dit, je n'ai pas pris la peine de tester generate() dans une conf dhcpd... tout feedback sera le bienvenu.
-
Y'a surement un truc qui m'echappe avec l'histoire de l'execute, parce que la ce qu'on a vu c'est que contrairement au chap challenge ici c'est la livebox qui choisi le challenge, et qui le communique dans les discover et request au serveur.
Alors pourquoi ne pas toujours envoyer la meme chaine statique ?
-
rien ne garantit qu'à terme le serveur acceptera la même requête une 2eme fois
-
Y'a surement un truc qui m'echappe avec l'histoire de l'execute, parce que la ce qu'on a vu c'est que contrairement au chap challenge ici c'est la livebox qui choisi le challenge, et qui le communique dans les discover et request au serveur.
Alors pourquoi ne pas toujours envoyer la meme chaine statique ?
quack a répondu à la question, et je ne vais que détailler sa réponse en exposant ma vision personnelle des choses.
Je me suis levé samedi 29 septembre 2018 et j'ai rapidement remarqué que je n'avais plus de connectivité Internet. Quelques diagnostics plus tard, j'ai remarqué que mon bail DHCP IPv4 chez Orange avait expiré faute d'avoir pu être renouvelé. Cela m'a bien entendu ramené sur ce forum où j'ai eu la chance de lire que le plus gros du travail pour déterminer le nouveau format à suivre pour les options DHCP avait déjà été effectué (franchement, j'ai trouvé ça assez génial). Un copier-coller plus tard, j'avais de nouveau une connectivité à Internet. Autrement dit : j'ai eu de la chance 1 - que d'autres personnes se soient penchées sur le problème avant moi et 2 - qu'il ait suffi de remplacer une chaîne statique par une autre. Est-ce que pour autant tout est bien qui finit bien ?
Eh bien non, pas forcèment.
D'abord, cet événement a prouvé que les échanges DHCP avec Orange étaient amenés à évoluer. Peut-être pas très souvent (mettons, au pifomètre, une fois tous les 3 ans ?), mais sur le long-terme, ça reste non-négligeable. S'ajoutent donc à ma TODO :
- monitorer mes baux DHCP pour avoir une alerte en cas de non-renouvellement prolongé
- suivre plus assidument ce qui se dit dans cette section du forum.
Et au milieu de ce qui se dit dans cette section du forum, on trouve des rumeurs, des extrapolations mais surtout des interrogations sur les prochains changements. Ces interrogations sont à mon sens bien fondées puisque la génération de l'option 90 est devenue plus complexe, ce qui n'augure pas d'une simplification dans le futur. Il me paraît donc parfaitement sensé de se préparer dès maintenant à plus de complexité.
Et où est-ce que le bât blesse en termes de complexité ? Réponse : nous avons largement les moyens de nous faciliter la génération des différentes chaînes statiques (à coup de Python, de shell, de JavaScript, etc.) mais nous manquons de moyens pour générer dynamiquement nos options DHCP. Et c'est problématique : on parle de perdre notre accès à Internet parce qu'un petit bout de software chargé d'échanger une poignée de paquets n'a pas la capacité d'effectuer quelques calculs plus ou moins triviaux à la volée.
Pour en revenir à generate() : l'intérêt est d'être capable de générer dynamiquement ses options DHCP dès maintenant. Comme ça, le jour où on s'aperçoit que les serveurs DHCP d'Orange exigent désormais une option générée dynamiquement (comme le fait déjà la LiveBox), il suffira d'adapter l'exécutable en conséquence.
Long story short : quand je me lève un matin sans Internet, je veux bien ajuster quelques lignes de Python/shell après avoir lu les dernières nouvelles sur lafibre.info, mais pas me taper du C.
Long story very short : j'ai fait un patch C de 474 lignes pour me préparer à un changement complètement hypothétique parce que je ne suis pas du matin.
-
et le lien vers le patch? :-[
c'est basé sur isc-dhcp-client?
sinon, j'attends de voir quand les équipements orange:
1. vérifieront le password dhcp dans le nouveau format mis en place il y a un mois
2. quand 1. sera fait, empêcheront le rejeu. Les packet capture de livebox montrent que la composante "aléatoire", telle qu'envoyé par la vraie livebox, reste fixe au moins pendant quelques minutes. Ça mérite confirmation, pour éviter de se faire des films pour rien ;D
-
pour info
dhclient: suspect value in domain_search option - discardedOrange envoie un 0 binaire en trop à la fin de l'option 119, d'où l'erreur notifiée par isc-dhcp-client. Ca sent le bon gros fail DEV / QA. Bravo les gars, vous êtes des champions du monde! 8) Erreur de développement C niveau débutant ::) ;D
-
et le lien vers le patch? :-[
Page précédente
-
et le lien vers le patch? :-[
Dans un de mes messages page 21 : https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg583155/#msg583155
Lien direct : https://xavier.kindwolf.org/2018-orange-dhcp/
La soumission du patch à l'ISC : https://bugs.isc.org/Public/Bug/Display.html?id=48316
c'est basé sur isc-dhcp-client?
Oui -- j'ai jeté un coup d'œil au code de Dibbler aussi, ça devrait être faisable aussi, mais avec moins de potentiel qu'isc-dhcp et leur "dhcp-eval".
pour info
dhclient: suspect value in domain_search option - discarded
Marrant ; je n'avais jamais remarqué parce que je ne demande rien relatif aux DNS à Orange :')
# Request only the minimal stuff + timings:
request subnet-mask, broadcast-address, routers, dhcp-lease-time, dhcp-rebinding-time, dhcp-renewal-time
-
Beau travail :D
Si t'avais un tipee je tiperais. Je voterais aussi sur la submission à l'ISC, s'il y avait un systeme de vote :-X
-
Ton 'generate' pourra recevoir des parametres issus du OFFER par exemple ? (un peu comme dhcp-eval)
-
Ton 'generate' pourra recevoir des parametres issus du OFFER par exemple ? (un peu comme dhcp-eval)
malheureusement, le travail de notre ami xavierg ne permet pas encore ça.
il faudrait ajouter une clause "on challenge" qui n'existe pas encore, qui permettrait de spécifier les paramètres qu'on veut utiliser (du genre https://superuser.com/questions/211411/executing-a-script-when-dhcpd-give-an-ip)
-
Normalement, si, c'est possible, via les nombreuses possibilités offertes par dhcp-eval (https://linux.die.net/man/5/dhcp-eval), auquel generate() n'est qu'un ajout. En théorie, on devrait pouvoir écrire un truc comme ça :
if exists challenge-je-sais-pas-quoi {
option authentication = generate("/etc/orange/auth", option("challenge-je-sais-pas-quoi"));
} else {
option authentication = generate("/etc/orange/auth");
}
-
Bon j'étais parti 3 semaines en déplacement pro puis vacs sans trop d'accès, coupure du net chez moi, je comprends mieux maintenant :D
Faudra refaire une conf/tuto une fois la branche 2.0 terminalisée histoire de tout remettre d'équerre avec les binaires patchés etc.
Bon boulot en tout cas à vous tous ;)
-
Hello,
Effectivement, les nouveaux abonnés orange (c'est mon cas) seraient très reconnaissant d'un tuto à jour :)
Avec mes remerciements anticipés !
-
Bonsoir,
Si Orange fait encore un changement, et qu'on est fucké pour un moment, c'est quoi l'alternative la moins pire avec la Livebox ? Je veux dire, pour lui faire faire le moins possible ? (avec un vrai routeur au cul quoi). Je veux dire, on peut pas la mettre en bridge si j'ai bien compris, donc faut doulementer NATer ? Rien de moins chiant que ça ?
-
Bonsoir,
Si Orange fait encore un changement, et qu'on est fucké pour un moment, c'est quoi l'alternative la moins pire avec la Livebox ? Je veux dire, pour lui faire faire le moins possible ? (avec un vrai routeur au cul quoi). Je veux dire, on peut pas la mettre en bridge si j'ai bien compris, donc faut doulementer NATer ? Rien de moins chiant que ça ?
On peut faire du MitM (man in the middle) DHCP. On réplique tout ce que la livebox envoie/reçoit qui concerne DHCP/DHCPv6 et on ignore tout le reste. Comme une sorte de relai DHCP ou le serveur relai (nous) s'octroie la configuration IP a la fin.
Mais pour ce faire il faudra développer du code spécifique (ou ca existe déjà peut-être je n'ai pas encore cherché).
C'est très 'future proof' mais nécessite de garder la livebox allumée.
-
Franchement, vu la merde que c'est la Livebox (et j'ai une pro…), je suis prêt à tout pour l'éviter en tant que routeur dans mon réseau.
-
Ouais, ce serait intéressant de faire le tour de l'existant en termes de relais DHCP pour voir si l'on pourrait reléguer la LiveBox à un rôle de simple "serveur dédié à faire tourner un client DHCP". Mais on risque de retomber sur la même problématique que le client DHCP "avancé" : la difficulté de déployer de nouveaux outils sur certains routeurs du marché.
-
IP perdue dans la nuit...
Un grand merci, cela a fonctionné du premier coup ! 8)
J'ai récupéré la même @IP (pas besoin de reconfigurer mes VPN). ;)
Au top ! 8)
Salut,
Tout fonctionnait correctement depuis le changement.
J'ai une nouvelle fois perdue mon IP dans la soirée du mercredi 17/10/2018, depuis impossible d'en récupérer une... Alors que tout fonctionne correctement en PPPoE.
Suis-je le seul dans ce cas ?
Merci
PS : J'habite LYON.
-
Pour ma part, j'ai encore pu renouveler mon bail DHCP ce matin (DHCPREQUEST/DHCPACK)
-
Tout fonctionnait correctement depuis le changement.
Chaine d'authentification avec ou sans le challenge + password ?
-
J'ai une nouvelle fois perdue mon IP dans la soirée du mercredi 17/10/2018, depuis impossible d'en récupérer une... Alors que tout fonctionne correctement en PPPoE.
Ici, à Rennes, j’ai toujours une IP et le dernier RENEW date de ce matin à 07:00:59 en IPv4 et à 08:43:20 en IPv6. J’utilise la chaîne au format « court » (sans mot de passe).
-
ubnt@EdgeRouter4:~$ show dhcp client leases
interface : eth0.832
lease time : 259200
last update: Thu Oct 18 09:22:34 CEST 2018
expiry : Sun Oct 21 09:22:33 CEST 2018
reason : RENEW
interface : eth0.838
lease time : 98742
last update: Thu Oct 18 04:56:26 CEST 2018
expiry : Fri Oct 19 08:22:06 CEST 2018
reason : RENEW
RENEW ce matin, rien à signaler de mon coté.
J'utilise la chaine longue.
-
Chaine d'authentification avec ou sans le challenge + password ?
Salut,
Sans le challenge + password.
=> 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Je n'arrive pas à utiliser le générateur ci-dessous. :-\
=> https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/
Aucune ligne n'est générée.
-
beaucoup de scripts autour de ce qui va créer les longues chaînes. Le mien est ici. Essayez-en un et voyez
#!/bin/sh
login='fti/abcdefg' #login userid
pass='hijklmn' #login password
livebox='4' #livebox version
maclivebox=01:23:45:67:89:AB #LiveBox Mac Address
serlivebox=ABCDE0123456789 #LiveBox Serial Number
tohex() {
for h in $(echo $1 | sed "s/\(.\)/\1 /g"); do printf %02x \'$h; done
}
#Authorisation String
#Fixed Part
f="00000000000000000000001a0900000558010341010d"
#RANDSTRING
r=$(dd if=/dev/urandom bs=1k count=1 2>&1 | md5 | cut -c1-16)
#RANDCHAR
id=${r%${r#??}}
#MD5 HASH (RANDCHAR+pass+RANDSTRING)
h=3c12$(tohex ${r})0313$(tohex ${id})$(echo -n ${id}${pass}${r} | md5 | cut -c1-32)
#Dhcp Authorisation string (FIXED+LOGIN+MD5HASH)
option90=$(echo ${f}$(tohex ${login})${h} | sed 's/\(..\)/\1:/g' | sed '$s/.$//')
rawoption11=$option90
#Dhcp Send options & Dhcp6c raw-options
dhcpclassidentifier='sagem'
userclass832='+FSVDSL_livebox.Internet.softathome.Livebox'${livebox}
userclass838=''\''FSVDSL_livebox.MLTV.softathome.Livebox'${livebox}
rawoption6='00:0b:00:11:00:17:00:18'
rawoption15='00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:3'$livebox
rawoption16='00:00:04:0e:00:05:73:61:67:65:6d'
#Dhcp VLAN 832 and 838 request options
requestoptions832='subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search, routers,domain-name-servers,option-90,option-120,option-125'
requestoptions838='subnet-mask,routers, ntp-servers, www-server, classless-routes'
#TV Decoder dhcp server Option-125
mac=$(echo ${maclivebox} | sed -e 's/://g')
lb=$(echo $(tohex 'Livebox')'20'$(tohex ${livebox}) | sed 's/\(..\)/\1:/g' | sed '$s/.$//')
option125=$(echo '00:00:0d:e9:24:04:06:'$(tohex ${mac} | cut -c 1-12 | sed 's/\(..\)/\1:/g' | sed '$s/.$//')":05:0f:$(tohex ${serlivebox} | sed 's/\(..\)/\1:/g' | sed '$s/.$//'):06:09:"$lb)
echo
echo '\033[1m+++++++++++++++++++++\033[0m'
echo '\033[1mDhcp Options VLAN 832\033[0m'
echo '\033[1m+++++++++++++++++++++\033[0m'
echo
echo '\033[1mSend Options\033[0m'
echo 'dhcp-class-identifier "'$dhcpclassidentifier'",user-class "'$userclass832'",option-90 '$option90
echo
echo '\033[1mRequest Options\033[0m'
echo $requestoptions832
echo
echo
echo '\033[1m+++++++++++++++++++++++\033[0m'
echo '\033[1mDhcp6c Options VLAN 832\033[0m'
echo '\033[1m+++++++++++++++++++++++\033[0m'
echo
echo '\033[1mSend Options\033[0m'
echo 'ia-pd 0,raw-option 6 '$rawoption6',raw-option 15 '$rawoption15',raw-option 16 '$rawoption16',raw-option 11 '$rawoption11
echo
echo
echo '\033[1m+++++++++++++++++++++\033[0m'
echo '\033[1mDhcp Options VLAN 838\033[0m'
echo '\033[1m+++++++++++++++++++++\033[0m'
echo
echo '\033[1mSend Options\033[0m'
echo 'dhcp-client-identifier 1:'$maclivebox',dhcp-class-identifier "'$dhcpclassidentifier'",user-class "'$userclass838'"'
echo
echo '\033[1mRequest Options\033[0m'
echo $requestoptions838
echo
echo
echo '\033[1m++++++++++++++++++++++++++++++++++\033[0m'
echo '\033[1mDhcp Advanced Server Options TVLAN\033[0m'
echo '\033[1m++++++++++++++++++++++++++++++++++\033[0m'
echo
echo '\033[1mNumber=\033[0m 125'
echo '\033[1mType=\033[0m string'
echo '\033[1mValue=\033[0m '$option125
echo
echo
-
Je n'arrive pas à utiliser le générateur ci-dessous. :-\
=> https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/
Aucune ligne n'est générée.
adblocker/noscript ?
-
Effectivement, sans asblocker la chaîne est générée.
Bon, par contre, cela ne corrige pas le problème de récupération @IP. ???
Salt : 16 chiffres aléatoires ?
Byte : A par défaut, testé avec d'autre lettre, dans tous les cas, je n'obtiens aucune @IP.
-
Peut-être un problème de ligne/fibre. Tu as essayé de brancher ta Livebox pour voir si la connexion se fait ?
-
Non pas besoin, en PPPoE toujours avec le PfSense, j'obtiens bien une @IP. :)
-
Comme indiqué plus avant mon script js n'a jamais été vérifié et je n'ai plus Orange pour le faire moi-meme.
essais avec les autres scripts (y'en a un en python et l'autre en shell de nivek1612). sinon manuellement.
-
Suite... :)
J'ai utilisé le script ci-dessous, malheureusement cela ne fonctionne pas mieux.
#!/bin/bash
login='fti/xxxxxx'
pass='xxxxxxx'
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})
Mon fichier de conf.
interface "igb0.832" {
send-interface "igb0";
vlan-id 832;
vlan-pcp 6;
# DHCP Protocol Timing Values
timeout 60;
retry 15;
reboot 0;
select-timeout 0;
initial-interval 1;
# DHCP Protocol Options
send dhcp-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh;
request subnet-mask, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, domain-search, routers, domain-name-servers, rfc3118-auth;
script "/sbin/dhclient-script";
}
pfSense 2.4.4-RELEASE (amd64)
-
Quelle est la trace de Wirehark?
Aussi avez-vous une LiveBox 3 ou 4?
-
LB 4
Quant à Wireshark, pas encore testé.
-
Là comme ça je ne vois pas de souci sur ta conf.
La valeur des paramètres "dhcp-class-identifier" et "user-class" correspondent bien à la Livebox que tu es sensé avoir connecté ?
-
Dans ce cas essaie de remplacer "Livebox3" par "Livebox4" dans le "user-class".
Possible qu'Orange valide ça aussi...
-
Cette conf aura correctement fonctionné pendant 2 ans.
Le changement LB3 à LB4 ne corrige pas le problème.
-
Wireshark svp
LB et pfsense permettent de comparer les deux
-
J'ai lancé un Wireshark lors d'un renew.
Comment affiner le filtrage ?
Je suis loin d'être un expert en analyse de trafic. :-[
Edit :
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0b08ee55
Seconds elapsed: 55
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: IntelCor_65:75:08 (00:1b:21:65:75:08)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 86.248.192.72
Option: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: IntelCor_65:75:08 (00:1b:21:65:75:08)
Option: (12) Host Name
Length: 7
Host Name: pfsense
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
Option: (255) End
Option End: 255
L'@IP demandée 86.248.192.72 correspond à celle que j'avais avant la coupure.
Que souhaitez-vous avoir d'autre comme info ?
Encore merci.
-
trouver la demande dhcp sur vlan 832 avec PRI0 6 comme celle montrée
puis inspectez la chaîne option-90 (authentification) pour le LB et le pfSense
Ce sera dans la section Protocole Bootstrap
-
J'ai lancé un Wireshark lors d'un renew.
Comment affiner le filtrage ?
Je suis loin d'être un expert en analyse de trafic. :-[
Edit :
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x0b08ee55
Seconds elapsed: 55
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: IntelCor_65:75:08 (00:1b:21:65:75:08)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 86.248.192.72
Option: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: IntelCor_65:75:08 (00:1b:21:65:75:08)
Option: (12) Host Name
Length: 7
Host Name: pfsense
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
Option: (255) End
Option End: 255
L'@IP demandée 86.248.192.72 correspond à celle que j'avais avant la coupure.
Que souhaitez-vous avoir d'autre comme info ?
Encore merci.
c'est la mauvaise demande dhcp dont vous avez besoin de celle émise sur le VLAN 832. Si c'est sur le VLAN 832, il manque la chaîne d'authentification
utilisez le programme wirehark, il est gratuit et facilite la recherche
-
Cela a été évoqué ces derniers jours dans le forum mais où ? ;)
Suivant la marque de la carte et l'OS, il faut faire un peu de paramétrage dessus pour voir les en-têtes 802.1q dans Wireshark. Par exemple sous Windows avec Intel :
https://www.intel.com/content/www/us/en/support/articles/000005498/network-and-i-o/ethernet-products.html
Le broadcast est bien sûr taggé, comme le reste.
-
c'est la mauvaise demande dhcp dont vous avez besoin de celle émise sur le VLAN 832. Si c'est sur le VLAN 832, il manque la chaîne d'authentification
utilisez le programme wirehark, il est gratuit et facilite la recherche
Il s'agit bien du vlan832.
Mon fichier de conf est paramétré pour envoyer la demande d'option 90 (rfc3118-auth).
N'ayant pas de trace de cette option dans la capture, il doit y avoir une erreur de syntaxe ou autre...
Personne n'utilise pfSense dans le coin ?
interface "igb0.832" {
send-interface "igb0";
vlan-id 832;
vlan-pcp 6;
# DHCP Protocol Timing Values
timeout 60;
retry 15;
reboot 0;
select-timeout 0;
initial-interval 1;
# DHCP Protocol Options
send dhcp-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh;
request subnet-mask, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, domain-search, routers, domain-name-servers, rfc3118-auth;
script "/sbin/dhclient-script";
}
-
Rassure-nous, tu n'as pas laissé les xx, les sa:lt, le zz et les ha:sh ?
Et c'est normal que tu "request" rfc3118-auth ?
-
Rassure-nous, tu n'as pas laissé les xx, les sa:lt, le zz et les ha:sh ?
Et c'est normal que tu "request" rfc3118-auth ?
Soit rassuré, j'ai bien remplacé les xx, les sa:lt, etc... ;)
La conf a fonctionné pendant 2 ans. 8)
Quant à la demande de "request" rfc3118-auth ?
Pour être honnête, aucune idée... A l'époque, j'ai testé comme ceci et cela fonctionnait.
-
Ça devient difficile de deviner ce qui cloche... est-ce que PfSense te fournit la sortie (stdout + stderr) de l'utilitaire dhclient ?
-
Comme tu dis, cela devient complexe.
Je ne pourrais malheureusement pas te répondre, manque de connaissance sur le sujet. :-[
Edit :
Avant :
send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh;
Après
send option-90 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh;
Et cela fonctionne !!! 8)
Option: (90) Authentication
Length: 70
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: "information floutée"
Un grand merci pour votre réactivité, en espérant être tranquille pour quelques mois...
-
Maintenant, je pense comprendre le problème. Je pense que pfSense a pris les modifications de code développées par OPNsense pour la prise en charge du VLAN dhclient et l’authentification Orange. C'est bien en tant que vrai source ouverte. OPNsense a implèmenté dhclient en utilisant 'option-90', qui est la syntaxe la plus correcte. pfSense avait utilisé rfc3118-auth pour le binary non officiel. Je soupçonne que vous avez récemment pris une mise à jour de correctif, ce qui explique pourquoi elle a soudainement cessé de fonctionner. Est-ce possible ? Ce qui est également étrange, c’est que OPNsense prenne en charge le paramètre vlan-pcp avec "vlan-parent" spécifiant l’interface d’envoi. Mais pfSense utilisait "send-interface".
-
Ah p****n, je croyais que c'était une spécificité du dhclient de FreeBSD qui te dispensait de déclarer le numéro de l'option... J'aurais dû être plus bavard... Bon, c'est bien si c'est réglé :)
Autre sujet : j'ai eu un feedback de l'ISC sur l'option generate(). Le mainteneur a qualifié la chose d'intéressante addition à la syntaxe de configuration mais a rappelé que la version 4.4.1 était la dernière version à apporter de nouvelles fonctionnalités. Du coup ils verront s'ils intègrent la fonctionnalité ou non dans la future 4.4.2 -- wait & see...
-
@kalistyan
Quelles sont vos vitesses?
J'ai une théorie selon laquelle s'ils sont pauvres, changez votre option et remplace
send-interface "igb0";
vlan-id 832;
vlan-pcp 6;
à
vlan-parent "igb0";
vlan-id 832;
vlan-pcp 6;
-
@nivek1612
C'est tout à fait possible, car je suis récemment passé de la version 2.4.3 à 2.4.4, mais n'ayant pas eu de coupure sur le coup, je n'ai pas fait le rapprochement.
Chose étrange, après vérification, je n'ai rien trouvé dans le changelog qui correspondrait...
Quant au débit, j'ai une moyenne de 550/250.
-
Hello
Apparemment ce n'est pas nouveau cette chaîne supplèmentaire dans l'option 90
Déjà en Janvier de cette année la LB l'envoyait
(https://preview.ibb.co/dxNXFf/2018-10-20-03-09-39-Window.png) (https://ibb.co/fdg3ML)
https://lafibre.info/remplacer-livebox/tv-sur-le-vlan-840-ne-fonctionne-plus/msg511398/?topicseen#msg511398
-
Oui, on sait... Même bien avant Janvier d'ailleurs (je dirais septembre/octobre 2017).
-
Oui, on sait... Même bien avant Janvier d'ailleurs (je dirais septembre/octobre 2017).
A lire le sujet c'est tout bouveau. Donc Orange a pu commencer depuis longtemps sa migration en douceur vers cette nouvelle methode.
Rien de rassurant du coup car nous ne sommes pas au début du processus.
Après Orange n'est pas le plus rapide a changer les choses sur son infrastructure ;D
-
je dirais septembre/octobre 2017
Soit un an d'écart entre l'introduction des nouveaux champs TLV et l'obligation de les mettre... ça a le mérite d'être cohérent. Peut-être que la vérification du mot de passe se fera à partir de septembre/octobre 2019 ? :)
-
Donc BT a 1 an pour venir en Zone AMII SFR :o
-
adblocker/noscript ?
Pour info, j'ai signalé le faux positif sur le forum officiel d'EasyList FR (la liste utilisée par Adblock et uBlock sur les navigateurs francophones), le problème lié aux bloqueurs de pubs devrait être résolu pour peu que la liste de filtres se soit mise à jour chez le client : https://forums.lanik.us/viewtopic.php?f=91&t=41981
Ne pas hésiter à faire ça en cas de soucis de faux positif, le mainteneur est très réactif.
-
Oui, on sait... Même bien avant Janvier d'ailleurs (je dirais septembre/octobre 2017).
septembre/octobre 2016 et peut être même avant.
(j'ai retrouvé un tcpdump de 2016 sur une Livebox Play)
-
Pour info, j'ai signalé le faux positif sur le forum officiel d'EasyList FR (la liste utilisée par Adblock et uBlock sur les navigateurs francophones), le problème lié aux bloqueurs de pubs devrait être résolu pour peu que la liste de filtres se soit mise à jour chez le client : https://forums.lanik.us/viewtopic.php?f=91&t=41981
Ne pas hésiter à faire ça en cas de soucis de faux positif, le mainteneur est très réactif.
nice. merci.
-
En attendant l'éventuelle intégration de l'opérateur generate() par l'ISC, je compte maintenir des paquets patchés pour Debian Stretch : https://xavier.kindwolf.org/2018-orange-dhcp/debian-repository.txt
-
Salut,
ça peut peut-être aider:
https://opensource.orange.com/fr/software/logiciels-de-la-maison/livebox/livebox-4-sagemcom/sg40_sip-fr-3-2-18-1_7-21-3-1/ (https://opensource.orange.com/fr/software/logiciels-de-la-maison/livebox/livebox-4-sagemcom/sg40_sip-fr-3-2-18-1_7-21-3-1/)
-
sudo mkdir -p /opt/softathome/toolchain/bcm96xx-arm-linux-gcc4.8.3-glibc2.19/usr
sudo chmod 777 /opt/softathome/toolchain/bcm96xx-arm-linux-gcc4.8.3-glibc2.19
sudo chown -R « user » : »user » /opt/softathome/toolchain/bcm96xx-arm-linux-gcc4.8.3-glibc2.19/usr/
sudo mkdir /home/ »user »/src
sudo chmod 777 /home/ »user »/src
L'Excellence Française...
-
:-D
mais docker est notre ami ;)
-
Marrant:
y'a Transmission dans les sources ... ;)
et le DPI de broadcom ... :o
-
Je croyais qu'il n'y avait rien d'intéressant dans les sources, ça aurait changé ? La dernière fois que j'ai compilé il n'y avait que la partie opensource, tout ce qui est spécifique à orange n’était pas présent.
-
En attendant l'éventuelle intégration de l'opérateur generate() par l'ISC, je compte maintenir des paquets patchés pour Debian Stretch : https://xavier.kindwolf.org/2018-orange-dhcp/debian-repository.txt
Merci beaucoup pour le dépôt :)
J’ai juste deux question :
* Y’a une raison pour laquelle isc-dhcp-server est aussi affecté ?
* Est-ce que tu comptes faire quelque chose de similaire avec dibbler (ou un autre client IPv6) ? Je n’ai clairement pas le niveau pour le faire moi-même et mon infra dépend de l’IPv6.
-
Merci beaucoup pour le dépôt :)
De rien... je tâcherai d'être réactif pour mettre à jour les paquets isc-dhcp si un DSA leur tombe dessus. J'espère que l'ISC inclura la fonctionnalité pour qu'elle se retrouve à terme packagée un peu partout.
* Y’a une raison pour laquelle isc-dhcp-server est aussi affecté ?
Oui : l'opérateur generate() n'a pas été ajouté à isc-dhcp-client mais à "dhcp-eval", un composant commun à isc-dhcp-client et isc-dhcp-server, d'où la recompilation de tous les paquets.
* Est-ce que tu comptes faire quelque chose de similaire avec dibbler (ou un autre client IPv6) ? Je n’ai clairement pas le niveau pour le faire moi-même et mon infra dépend de l’IPv6.
Ça n'est pas exclu. Je me suis pour le moment concentré sur isc-dhcp puisque c'est ce que j'utilise. Là, je pense que c'est fini, donc je dois pouvoir me pencher sur Dibbler. Est-ce que tu peux partager ton fichier de configuration Dibbler anonymisé ? Ça me ferait un bon point de départ...
-
Je pense que quitte à faire la même chose pour IPv6, autant le faire sur autre chose que dibbler, puisqu'il n'est plus vraiment maintenu...
-
Au passage, si quelqu'un veut s'amuser à tester un generate() dans la configuration d'un dhclient -6, ça m'intéresse.
-
Ça n'est pas exclu. Je me suis pour le moment concentré sur isc-dhcp puisque c'est ce que j'utilise. Là, je pense que c'est fini, donc je dois pouvoir me pencher sur Dibbler. Est-ce que tu peux partager ton fichier de configuration Dibbler anonymisé ? Ça me ferait un bon point de départ...
Pas de soucis :) https://paste.swordarmor.fr/raw/HrvY
La double option 11 est voulue, pour une raison que j’ignore ça ne marche pas avec une seule. Son contenu est exactement celui de l’option 90 en IPv4.
Si jamais tu as besoin du fichier complet, je pourrai te le fournir en privé.
-
Je pense que quitte à faire la même chose pour IPv6, autant le faire sur autre chose que dibbler, puisqu'il n'est plus vraiment maintenu...
Tu utilises quel client pour l’IPv6 chez toi ?
-
Au passage, si quelqu'un veut s'amuser à tester un generate() dans la configuration d'un dhclient -6, ça m'intéresse.
ISC DHCP client ne supporte pas la délégation de préfixe IPv6, non ?
Edit: Il semble que si en fait... Faut que je mette un lab en place chez moi pour jouer un peu avec.
Edit2: Apparemment il faut un patch pour pouvoir indiquer la taille du préfixe demandé, ce qui est obligatoire chez Orange...
Edit3: Le patch semble intégré dans la version 4.4.0
-
Tu utilises quel client pour l’IPv6 chez toi ?
Toujours dibbler, mais j'aimerais un truc un peu plus maintenu. Jusqu'à présent c'était le plus simple à patcher pour la CoS notamment, mais je pense changer pour une solution où la CoS est appliquée par mon switch (qui sait le faire, autant s'en servir). Si je pouvais arriver à utiliser le firmware de mon ER4 sans aucune modification ça serait top.
Du coup il ne reste que la problématique du client DHCP6-PD sur EdgeOS (ils sont toujours à wide-dhcp6 qui n'est plus maintenu depuis des années et ne supporte AUCUNE option...).
-
La double option 11 est voulue
En fait si on la met une seule fois, alors elle est envoyée dans le paquet Solicit mais pas dans le Request, et du coup pas de réponse du serveur...
-
@zoc OPNsense maintient dhclient et dhcp6c avec les options requises et la CoS. Ils sont également heureux de travailler et le sel de hachage a besoin quand ils se présentent
-
@zoc OPNsense maintient dhclient et dhcp6c avec les options requises et la CoS.
Oui, je sais, mais je ne vais pas changer pour OPNSense (ni pfSense non plus d'ailleurs).
-
Toujours dibbler, mais j'aimerais un truc un peu plus maintenu. Jusqu'à présent c'était le plus simple à patcher pour la CoS notamment, mais je pense changer pour une solution où la CoS est appliquée par mon switch (qui sait le faire, autant s'en servir). Si je pouvais arriver à utiliser le firmware de mon ER4 sans aucune modification ça serait top.
En IPv4 et Ipv6 sur la même interface ? Certains switchs ont des limitations de ce genre là. Quel modèle de switch ?
-
Mon switch (ES-24-LITE) ne peut pas appliquer une policy IPv6 et IPv4 sur le même port. Par contre il peut appliquer une policy en in ou en out (en théorie d'après la doc, je n'ai pas encore essayé). L'idée c'est donc d'appliquer la QoS pour IPv4 en in sur le port relié au routeur, et en out sur le port qui va à l'ONT pour IPv6.
Edit:
Apparemment pas de policy en out sur mon switch, même s'il y a une commande CLI pour le faire :( https://community.ubnt.com/t5/EdgeSwitch/Failed-to-attach-one-or-more-policies-to-the-interface/td-p/1521464 https://community.ubnt.com/t5/EdgeSwitch/DiffServ-service-policy-out/td-p/2440719
Quoi qu'il en soit, pour l'instant il est impossible de faire de l'IPv6 chez Orange avec EdgeOS sans modifications. Donc à la limite je peux me contenter de faire la CoS IPv4 sur le switch et d'installer dibbler (ou autre) pour IPv6.
-
J'ai un SG500-28 de chez Cisco qui me sert a rien faudrait que je regarde s'il est capable de faire ça
-
pour sg-500 de cisco à tester,
Class of service
Port based; 802.1p VLAN priority based; IPv4/v6 IP precedence/ToS/DSCP based; DiffServ; classification and re-marking ACLs, Trusted QoS
Queue assignment based on differentiated services code point (DSCP) and class of service (802.1p/CoS)
Sur la gamme classique de cisco, seul les switch catalyst de serie 3000 et supérieur peuvent avoir la COS en IN sur un vlan (pas en out), c'est à dire un switch de niveaux 3 et non un switch de niveaux 2 amélioré, un 2960L (fanless) ne sait faire de le cos que sur une interface et non un vlan
Perso j'ai un 3560CX (fanless), j'ai réussi à avoir une ip pour la partie ipv4 (attention cela ne fonctionne pas avec un dhclient modifié) mais pas ipv6. je dois refaire des tests pour la partie ipv6.
pour les switch fanless de la gamme classique les versions poe sont des grilles pain
-
Le SG350-28, fonctionne très bien pour la COS en sortie sur le port SFP avec SFP-ONT en ipv4 et ipv6. Donc pour le SG500 sa doit fonctionner.
Il faut d'abord créer les ACE sur MAC/IPV4 et IPV6 dans ACCES-CONTROL, puis aller dans QOS ADVANCED, et faire une CLASS MAPPING, puis toujours dans QOS ADVANCED créer une POLICY, puis faire une POLICY CLASS MAP. Et après reste plus qu'a faire le POLICY BINDING en sortie.
Je met les screens si ça intéresse quelqu'un (ne pas tenir compte du vlan840, c'est parce que c'est le switch qui fait l'igmp chez moi)
-
Vu que ça parle switch, sur mon Dlink DGS-1210-10P (8 ports RJ45 + 2 SFP dont un utilisé par l'ONT-SFP Orange), je peux également mettre des ACL IPv4 + IPv6 sur un même port.
Autant en IPv4, ça fonctionne mais pas en IPv6 (pas de réponse aux requêtes Dibbler).
Voici la configuration mise en place:
Création de 2 ACL (les ACL se positionnent sur un port et non un vlan):
- une ACL IPv4: DHCPv4_SetCoSto6
- une ACL IPv6: DHCPv6_SetCoSto6
Dans l'ACL "DHCPv4_SetCoSto6" (du coup le nom n'est plus adéquat car j'ai rajouté une seconde règle pour l'IGMP par la suite, mais on ne peut pas renommer une ACL sans tout supprimer et recréer), j'ai 2 règles:
- règle 1 pour forcer la priorité 6 aux requêtes DHCPv4
- règle 2 pour forcer la priorité 5 au flux IGMP (pour la TV)
(https://i.postimg.cc/GtW7vkjy/DGS-1210-10p-ipv4-regle1.png)
(https://i.postimg.cc/zD48x6tn/DGS-1210-10p-ipv4-regle2.png)
Dans l'ACL "DHCPv6_SetCoSto6", j'ai 1 règle:
- règle 1 pour forcer la priorité 6 aux requêtes DHCPv6
(https://i.postimg.cc/P5tcyMjW/DGS-1210-10p-ipv6-regle1.png)
Et j'applique tout ça sur un port :
(https://i.postimg.cc/sxdHhYmZ/DGS-1210-10p-ACL.png)
Mais comme je l'ai indiqué plus haut: en IPV4 tout est OK (DHCP, flux TV) mais en IPv6 pas de réponse via Dibbler. Je vois bien le flux passer avec un Wireshark, mais la priorité 6 en IPv6 n'est pas appliquée.
J'ai déjà essayé plusieurs choses sans succès:
- appliquer l'ACL IPv6 seul sans l'ACL IPv4
- appliquer les ACL sur le port SFP fibre ou sur le port RJ45 du routeur
Pour le moment, je sèche pour l'IPv6.
Un bug du firmware Dlink est possible ? J'ouvrirai bien un ticket chez Dlink, mais il faut que je sois sur de mon coup.
-
Si je mets des côté les histoires de configuration de switchs, je note que Dibbler reste assez utilisé malgré son statut de non-maintenance...
-
Hj67, peux-tu voir pour rajouter une ACL type MAC qui filtre que le vlan832 ? parce que cela ne doit s'appliquer que sur le vlan 832.
-
Je ne crois pas avoir cette possibilité.
Si je filtre sur le 832, je perds le 840 pour la TV, non ? (où j'applique la prio 5 sur le flux IGMP).
Je regarderais à l'occasion.
-
xavierg>
J'ai testé ton patch en ipv4 et ipv6, ça marche parfaitement! 8)
Les deux auth successives bootp et dhcpv6 sont différentes (alors que la LB envoie la même pendant un certain temps), mais ça ne semble pas gêner les équipements orange.
As-tu essayé d'altérer la TOS (COS CS6) et la priorité 802.1q (6) dans le code de isc-dhcp?
J'arrive sans problème à envoyer COS=CS6. La socket LPF PF_PACKET SOCK_RAW ne bronche pas.
Par contre, même si j'ai configuré le VLAN egress map à "6:6" de mon interface orange 832, et que j'ajoute dans le code LPF un setsockopt (sock, SOL_SOCKET, SO_PRIORITY, &tag ... (int tag=6) sur la socket LPF, la VLAN priority capturée par wireshark reste 0.
(seul work around qui marche pour moi pour l'instant: mapping egress à "0:6", et tout le traffic sort avec la prio 802.1q égale à 6. Il faut utiliser netfilter avec "classify set-class" pour remettre le reste du traffic "non network control" sur une autre classe, non mappée dans le egress map, pour éviter que tout soit envoyé à orange avec la prio 6, sinon perte de débit ...)
-
J'ai testé ton patch en ipv4 et ipv6, ça marche parfaitement! 8)
Cool, merci pour le feedback :)
Les deux auth successives bootp et dhcpv6 sont différentes (alors que la LB envoie la même pendant un certain temps), mais ça ne semble pas gêner les équipements orange.
Si ça s'avère nécessaire, on pourra implèmenter la conservation de l'auth générée pendant un certain temps dans le script d'auth... C'est l'avantage de déléguer le travail à un exécutable externe, ça ouvre pas mal de possibilités.
As-tu essayé d'altérer la TOS (COS CS6) et la priorité 802.1q (6) dans le code de isc-dhcp?
Moi non : je me contente de jouer avec vconfig et Netfilter/iptables comme décrit dans d'autres topics de ce forum. Mon script /etc/orange/up pour monter l'interface réseau vers l'ONT est le suivant :
#!/bin/bash
script_filepath="$(readlink -f "${0}")"
script_dirpath="$(dirname "${script_filepath}")"
IFACE="${1:-eth0.832}"
DHCLIENT_CONF="${script_dirpath}/dhclient.conf"
# Ensure DHCP packets get sent with VLAN priority 6:
# Step 1: map skb to VLAN priorities:
# skb 0 (default): VLAN priority 6; used for packets we could not target
# with iptables:
vconfig set_egress_map "${IFACE}" 0 6
# skb 1: VLAN priority 0 (all packets but those assigned to skb 6)
vconfig set_egress_map "${IFACE}" 1 0
# skb 6: VLAN priority 6
vconfig set_egress_map "${IFACE}" 6 6
# Step 2: classify traffic accordingly:
iptables --table 'mangle' --append 'POSTROUTING' --out-interface "${IFACE}" --jump 'CLASSIFY' --set-class '0000:0001'
iptables --table 'mangle' --append 'POSTROUTING' --out-interface "${IFACE}" --protocol 'udp' --dport '67' --jump 'CLASSIFY' --set-class '0000:0006'
# Run dhclient with the Orange-specific configuration file:
dhclient -v -cf "${DHCLIENT_CONF}" "${IFACE}"
dhclient_rc=$?
# There used to be extra steps here, but they have been moved to dhclient
# hooks.
exit "${dhclient_rc}"Ça correspond, si je ne m'abuse, à ce que tu décris à la fin de ton post. Je trouve aussi que ça n'est pas très intuitif mais ça fait le boulot depuis un bon moment et je n'ai jamais cherché à patcher isc-dhcp-client juste pour ça. Cela dit, tu n'es pas le premier à patcher isc-dhcp-client pour ce besoin : zoc avait fait le même patch (juste un setsockopt ajouté dans lpf.c), et mystogan l'utilise cumulé à mon patch pour generate().
-
Ça correspond, si je ne m'abuse, à ce que tu décris à la fin de ton post. Je trouve aussi que ça n'est pas très intuitif mais ça fait le boulot depuis un bon moment et je n'ai jamais cherché à patcher isc-dhcp-client juste pour ça. Cela dit, tu n'es pas le premier à patcher isc-dhcp-client pour ce besoin : zoc avait fait le même patch (juste un setsockopt ajouté dans lpf.c), et mystogan l'utilise cumulé à mon patch pour generate().
Ah, je suis preneur du bout de code, si quelqu'un a réussi à dompter la priorité skb (socket buffer linux) de la socket LSP de isc-dhclient (socket(PF_PACKET, SOCK_RAW, htons((short)ETH_P_ALL).
-
Mon patch pour forcer la priorité SKB à 6, pour ISC-DHCP (4.1, mais doit s’appliquer sur les suivants):
https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/?action=dlattach;attach=33988
-
merci!
Par contre j'arrive pas à le transformer en prio 802.1q avec mon debian stretch et ma config vlan 832 egress map "6:6".
Je revérifierai tout ça à l'occasion ... ???
-
Pour info j'ai indentifié mon erreur d'assignation de priorité VLAN = 6 et DSCP = CS6 avec debian.
Du coup, pas besoin de "mangle" la "meta-class" de tout le traffic.
J'assignais le mapping egress VLAN trop tard, après les handshake ARP/DHCP/NDP, en utilisant la stanza up comme ceci:
# WAN vlan 832 internet
auto enp1s0.832
iface enp1s0.832 inet dhcp
up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
iface enp1s0.832 inet6 dhcp
up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
request_prefix 1
accept_ra 2
C'est corrigé avec la stanza pre-up, qui est exécutée avant les handshakes:
# WAN vlan 832 internet
auto enp1s0.832
iface enp1s0.832 inet dhcp
pre-up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
iface enp1s0.832 inet6 dhcp
pre-up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
request_prefix 1
accept_ra 2
Pour info, la config nftables qui va avec, pour l'assignation des bons DSCP et prio uniquement pour les paquets concernés:
table inet fltr46 {
chain assign-orange-prio {
ip version 4 udp sport { bootpc, bootps } ip dscp set cs6 meta priority set 6 counter comment "handled by isc-dhclient LPF socket, hence unfiltered"
ip6 nexthdr icmpv6 icmpv6 type { nd-router-solicit, nd-neighbor-solicit } ip6 dscp set cs6 meta priority set 6 counter comment "rule hit, but priority not set"
ip6 nexthdr udp udp sport { dhcpv6-server, dhcpv6-client } ip6 dscp set cs6 meta priority set 6 counter comment "dhcp6 packets, sent by isc-dhclient"
}
chain postrouting {
type filter hook postrouting priority 0; policy accept;
oifname vmap { $if_wan : goto assign-orange-prio }
}
chain output {
type filter hook output priority 0; policy accept;
oifname vmap { $if_wan : goto assign-orange-prio }
}
}
table arp arp4 {
chain output {
type filter hook output priority 0; policy accept;
oifname $if_wan meta priority set 6 counter comment "rule hit, but priority not applied to arp packets, why?"
}
}
-
Bon, sinon les gars, je sais pas si vous avez vu, mais depuis quelques jours il y a une nouvelle option renvoyée par les serveurs DHCP d'Orange, la 119 (domain-search).
Chez moi elle contient "NIC.access.orange-multimedia.net.", sachant que "NIC" c'est probablement "Nice" puisque je suis pas loin...
Reste à savoir ce que nous prépare encore Orange ;)
-
Je viens de faire le test et le serveur DHCP orange a bien envoyé l'option 119. Il y a "PUT.access.orange-multimedia.net". Je suis dans le 92.
-
Un truc en rapport avec la VoIP ? Car c'est la même chose sauf qu'ils ont supprimé sbct3g.
Domain search : PUT.access.orange-multimedia.net
SIP : sbct3g.PUT.access.orange-multimedia.net
Cette option remplacerait t-elle domain-name orange.fr dans la config SIP ?
Les majuscules c'est donc bien le nom des villes (à noter que le DNS répond bien pour les 9)
AUB : Aubervilliers
PUT : Puteaux
NIC : Nice
LYO : Lyon
MAR : Marseille
BOR: Bordeaux
DIJ : Dijon
CLE : Clermont-Ferrand
REN : Rennes
J'vais pas faire tout la liste ;)
On notera que certaines villes renvoient les mêmes IP, j'ai par exemple trouvé Rennes et Bordeaux.
-
Cette option remplacerait t-elle domain-name orange.fr dans la config SIP ?
"domain-name" est toujours à "orange.fr" chez moi en tout cas. Seul "domain-search" est nouveau.
Si c'est lié au service SIP, alors on peut s'attendre à la disparition de l'option 120 qui fait doublon du coup (pour l'instant je l'ai toujours, sans doute le temps de déployer une mise à jour des box). Quoi qu'il en soit, mon serveur DHCP publie désormais également l'option 119 pour ma Livebox ;).
Ca va également compliquer l'écriture des tutos pour la téléphonie puisque chaque utilisateur devra choisir le bon FQDN en fonction de sa "plaque".
-
Ca va également compliquer l'écriture des tutos pour la téléphonie puisque chaque utilisateur devra choisir le bon FQDN en fonction de sa "plaque".
par forcement, c'est un 'domain-search' dns donc si on cherche a résoudre 'sbct3g' ca va completer tout seul avec le FQDN recu par l'option 119.
Ca simplifie pas mal les choses en fait.
-
Du coup si ça fait effectivement doublon avec la 120, j'ai du mal à voir l'avantage de celle-ci.
Car ça voudrait dire que la livebox va résoudre uniquement "sbct3g", mais si par exemple les serveurs changent de nom (genre sip.XXX.access...), il faudra mettre à jour le firmware, alors que que si on envoie l'adresse complète via la 120, on peut bien mettre ce qu'on veut et ça s'adapte sans toucher au FW.
Et pour l'histoire de la simplification, j'ai pas l'impression que ça en soit vraiment une, puisque qu'il faudra toujours regarder la réponse DHCP d'orange pour savoir quoi mettre. Puisque qu'il faudra bien configurer le serveur DHCP du routeur. A moins qu'il existe pour cette option un relais qui la configure automatiquement ?
-
Puisque qu'on est dans le téléphone, j'ai remarqué que ma box demande d'autres noms de domaines en rapport avec le réseau mobile notamment :
-sgw.mobile.orange.fr
-psegw.gan.mnc002.mcc208.pub.3gppnetwork.org
Est-ce que ça serait lié au H323, des fois que le SIP échoue ?
-
Pour résumer, on doit désormais fournir quelles options dans la conf du "faux" serveur DHCP ?
option 90, 119, 120 et 125?
-
Puisque qu'on est dans le téléphone, j'ai remarqué que ma box demande d'autres noms de domaines en rapport avec le réseau mobile notamment :
-sgw.mobile.orange.fr
-psegw.gan.mnc002.mcc208.pub.3gppnetwork.org
Est-ce que ça serait lié au H323, des fois que le SIP échoue ?
h323 avec sgw, psecgw et 3gpp, non peu de chances :)
VoWifi sans doute plus. (sans certitudes).
-
h323 avec sgw, psecgw et 3gpp, non peu de chances :)
VoWifi sans doute plus. (sans certitudes).
Ah oui c'est logique, cela dit, ça sort d'une pro V2 qui n'a pas été mise à jour depuis 2014 (si je m'en réfère aux messages évoquant le firmware) Orange testait déjà cette fonctionnalité à l'époque ? Je serais curieux de savoir si c'est pareil pour la play et la 4.
-
Pour résumer, on doit désormais fournir quelles options dans la conf du "faux" serveur DHCP ?
option 90, 119, 120 et 125?
A priori, oui. Limite tu peux essayer de virer l'option 120 voir si la LB se connecte quand même. Au moins on saura si le mécanisme est déjà en place :)
-
par forcement, c'est un 'domain-search' dns donc si on cherche a résoudre 'sbct3g' ca va completer tout seul avec le FQDN recu par l'option 119.
Ca simplifie pas mal les choses en fait.
Ce que je voulais dire par là, c'est qu'on pourra plus écrire "mettez NIC.access.orange-multimedia.net dans l'option domain-search de votre serveur DHCP" dans un tuto , puisque le suffixe de recherche dépendra de la localisation du client, et ne ne suis pas sur que tous soient capables de déterminer celui à utiliser...
-
Car ça voudrait dire que la livebox va résoudre uniquement "sbct3g", mais si par exemple les serveurs changent de nom (genre sip.XXX.access...)...
Le "sbct3g" peut très bien être dans le profil de configuration que la box télécharge régulièrement ;)
Et du coup ne pas avoir le reste de l'adresse SIP dans le profil permet d'avoir un profil identique au niveau national, la répartition de charge se faisant grâce à l'option 119 retournée par le serveur/relais DHCP auquel le client s'adresse.
-
A priori, oui. Limite tu peux essayer de virer l'option 120 voir si la LB se connecte quand même. Au moins on saura si le mécanisme est déjà en place :)
En hexa ça donne quoi cette option 119?
voilà le début de mon option 120 (je ne me souviens plus si elle provient du net ou si c'est une analyse des trames)
00:06:73:62:63:74:33:67:03:41:55:42:06:61:63:63:65:73:73:
je suis visiblement dépendant de AUB. Je tronque juste avant la portion en gras ou je laisse un 00 devant?
Ce que je voulais dire par là, c'est qu'on pourra plus écrire "mettez NIC.access.orange-multimedia.net dans l'option domain-search de votre serveur DHCP" dans un tuto , puisque le suffixe de recherche dépendra de la localisation du client, et ne ne suis pas sur que tous soient capables de déterminer celui à utiliser...
une observation : es-ce que les "NIC" dépendent du début du reverse ipv4 ? si oui ça pourrait donner une piste pour le trouver facilement (avec un tableau). C'était le cas avant en ADSL où Orange utilise la forme Aville-...
sur mon ipv4 le reverse commence par lfbn-idf3-1
-
Ce que je voulais dire par là, c'est qu'on pourra plus écrire "mettez NIC.access.orange-multimedia.net dans l'option domain-search de votre serveur DHCP" dans un tuto , puisque le suffixe de recherche dépendra de la localisation du client, et ne ne suis pas sur que tous soient capables de déterminer celui à utiliser...
ah ok.
ou faudrait pouvoir propager le 119 reçu sur le wan dans la conf du serveur dhcp du lan...pas forcement simple suivant les routeurs.
ou a la main, ca se voit pas dans l'interface de la livebox ? ou via l'api sysbus ( http://192.168.1.1/sysbus/NMC:getWANStatus cf https://github.com/rene-d/sysbus)
-
Le "sbct3g" peut très bien être dans le profil de configuration que la box télécharge régulièrement ;)
Et du coup ne pas avoir le reste de l'adresse SIP dans le profil permet d'avoir un profil identique au niveau national, la répartition de charge se faisant grâce à l'option 119 retournée par le serveur/relais DHCP auquel le client s'adresse.
Dans ce sens d'accord.
Mais vu qu’actuellement le serveur SIP est donné par l'option 120 (qui dépend aussi du DHCP utilisé), il n'y a pas besoin d'avoir sbct3g dans le profil. Donc que ce soit l'une ou l'autre méthode ça ne simplifie rien en fait. C'est juste une autre manière de faire.
-
Vu sur une LB4, la 119 (domain-search) ne remplace pas, à ce jour, la 120 (SIP) :
Si j'ajoute la 119 à la 120 : la téléphonie marche toujours,
puis si je delete la 120 en laissant la 119 : plus de téléphone ;)
Pour les gens sous RouterOS, on peut reprendre l'option 120 pour créer la 119, en tronquant le début de la 120 :
/ip dhcp-server option
add code=120 name=SIP value=0x0006736263743367034d535206616363657373116f72616e67652d6d756c74696d65646961036e657400
add code=119 name=Domain-search value=0x034d535206616363657373116f72616e67652d6d756c74696d65646961036e657400
4d5352 correspond à MSR, certainement Montsouris, à Paris.
-
dans le 14eme à Paris:
Option: (119) Domain Search
Length: 34
FQDN: MSR.access.orange-multimedia.net
-
Proche de Strasbourg: STR.access.orange-multimedia.net
J'ai un peu regardé dans l'historique des baux, c'était déjà présent le 13/11 (peut être même avant, mais je n'ai plus d'historique).
-
Voici une configuration pour un Edgerouter, avec un VLAN pour la Livebox. Ça inclut l'option 119.
set interfaces ethernet eth2 description LAN_LIVEBOX
set interfaces ethernet eth2 duplex auto
set interfaces ethernet eth2 speed auto
set interfaces ethernet eth2 vif 832 address 192.168.20.1/24
set interfaces ethernet eth2 vif 832 description 'VLAN VoIP'
set service dhcp-server disabled false
set service dhcp-server global-parameters 'option rfc3118-authentication code 90 = string;'
set service dhcp-server global-parameters 'option SIP-servers code 120 = string;'
set service dhcp-server global-parameters 'option Vendor-Specific-Information code 125 = string;'
set service dhcp-server hostfile-update disable
set service dhcp-server shared-network-name Network_Livebox authoritative enable
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 default-router 192.168.20.1
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 dns-server 80.10.246.136
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 dns-server 81.253.149.6
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 domain-name 'orange.fr PUT.access.orange-multimedia.net'
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 lease 259200
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 start 192.168.20.20 192.168.20.22
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 subnet-parameters 'option Vendor-Specific-Information 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;'
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 subnet-parameters 'option rfc3118-authentication 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;'
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 subnet-parameters 'option SIP-servers 00:06:73:62:63:74:33:67:03:50:55:54:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;'
-
Voici une configuration pour un Edgerouter, avec un VLAN pour la Livebox. Ça inclut l'option 119.
Beau travail ! Merci.
-
fttmeh> Je n'ai pas d'Edgerouter, mais pour moi, la ligne ci-dessous n'est pas correcte :
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 domain-name 'orange.fr PUT.access.orange-multimedia.net'orange.fr est le domaine-name , c'est OK (option 15)
Par contre, le XXX.access.orange-multimedia.net serait à mettre dans le domain-search list (option 119)
-
Oui, je suis d'accord, et d'ailleurs si on veut vraiment faire exactement ce que fait la box, on ne peut pas utiliser la commande "domain-name XXXXXX" d'EdgeOS, car ça va se transformer en "domain-name XXXXXX" et "domain-search XXXXXX" dans le fichier de config du serveur DHCP.
Du coup, moi je n'utilite plus "domain-name" directement, mais plutôt ça:
shared-network-name VLAN_LIVEBOX_DHCP {
authoritative enable
subnet 192.168.10.0/24 {
default-router 192.168.10.1
dns-server 80.10.246.3
dns-server 81.253.149.10
lease 172800
start 192.168.10.30 {
stop 192.168.10.50
}
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;"
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
subnet-parameters "option domain-search "NIC.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
}
}
-
fttmeh> Je n'ai pas d'Edgerouter, mais pour moi, la ligne ci-dessous n'est pas correcte :
set service dhcp-server shared-network-name Network_Livebox subnet 192.168.20.0/24 domain-name 'orange.fr PUT.access.orange-multimedia.net'orange.fr est le domaine-name , c'est OK (option 15)
Par contre, le XXX.access.orange-multimedia.net serait à mettre dans le domain-search list (option 119)
Au fait, EdgeOS transforme ça :
domain-name "orange.fr PUT.access.orange-multimedia.net"
En (dans le fichier de config du serveur DHCP - /opt/vyatta/etc/dhcpd.conf ) :
option domain-name "orange.fr";
option domain-search "orange.fr", "PUT.access.orange-multimedia.net";
La seule façon d'avoir seulement XXX.access.orange-multimedia.net dans l'option domain-search (119) est de faire comme @zoc mentionne ci-haut.
Bien que faire de cette façon ne soit pas exactement ce qui fait la box, tout fonctionne correctement.
-
Oui, je suis d'accord, et d'ailleurs si on veut vraiment faire exactement ce que fait la box, on ne peut pas utiliser la commande "domain-name XXXXXX" d'EdgeOS, car ça va se transformer en "domain-name XXXXXX" et "domain-search XXXXXX" dans le fichier de config du serveur DHCP.
C'est vrai, si on veut faire exactement ce que la box fait, il faut faire comme @zoc dit. EdgeOS utilise la valeur de l'option domain-name pour remplir les options 119 et 15 (Cf. mon post juste avant).
Enfin, pour l'instant tout fonctionne pour moi. Je vois peu de risque d'avoir deux search-domains pour la box, car c'est du Linux qui tourne dans la box et depuis longtemps Linux gère bien au moins deux search domains.
-
C'est vrai, si on veut faire exactement ce que la box fait, il faut faire comme @zoc dit. EdgeOS utilise la valeur de l'option domain-name pour remplir les options 119 et 15 (Cf. mon post juste avant).
Enfin, pour l'instant tout fonctionne pour moi. Je vois peu de risque d'avoir deux search-domains pour la box, car c'est du Linux qui tourne dans la box et depuis longtemps Linux gère bien au moins deux search domains.
Perso je passe par dnsmasq, comme ça je peux faire ce que je veux ...
dns {
forwarding {
cache-size 1024
listen-on lo
listen-on eth0.1
listen-on eth0.30
name-server 8.8.8.8
name-server 8.8.4.4
options bogus-priv
options domain-needed
options rebind-localhost-ok
options stop-dns-rebind
options dhcp-option=tag:LIVEBOX,15,orange.fr
options dhcp-option=tag:LIVEBOX,90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
options dhcp-option=tag:LIVEBOX,119,PUT.access.orange-multimedia.net.
options dhcp-option=tag:LIVEBOX,120,00:06:73:62:63:74:33:67:03:50:55:54:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00
options dhcp-option=tag:LIVEBOX,125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
options cname=library.invitro.lan,duosyn.invitro.lan
}
}
-
dns {
listen-on lo
listen-on eth0.1
listen-on eth0.30
name-server 8.8.8.8
name-server 8.8.4.4
Je vois que tu n'utilises pas le VLAN 832 ni les serveurs DNS d'Orange (80.10.246.3 et 81.253.149.10). Utilises-tu la livebox pour ton téléphone fixe ?
-
Je vois que tu n'utilises pas le VLAN 832 ni les serveurs DNS d'Orange (80.10.246.3 et 81.253.149.10). Utilises-tu la livebox pour ton téléphone fixe ?
Si si j'utilise le vlan 832 et les DNS orange ... Et oui j'utilise le fix de la LB.
Voici un plus gros fragment de ma config
interfaces {
bridge br0 {
aging 300
bridged-conntrack disable
description "br0 -> eth2.838 LIVEBOX (VoD)"
hello-time 2
max-age 20
priority 0
promiscuous disable
stp false
}
bridge br1 {
aging 300
bridged-conntrack disable
description "br1 -> eth2.840 LIVEBOX (multicast)"
hello-time 2
max-age 20
priority 0
promiscuous disable
stp false
}
ethernet eth0 {
description LAN
duplex auto
speed auto
vif 1 {
address 192.168.0.1/24
description LAN_HOME
ipv6 {
dup-addr-detect-transmits 1
router-advert {
cur-hop-limit 64
link-mtu 0
managed-flag false
max-interval 600
other-config-flag false
prefix ::/64 {
autonomous-flag true
on-link-flag true
preferred-lifetime 14400
valid-lifetime 18000
}
reachable-time 0
retrans-timer 0
send-advert true
}
}
}
}
ethernet eth1 {
description ISP
duplex auto
speed auto
vif 832 {
address dhcp
description ISP_DATA
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox3";"
client-option "send rfc3118-auth XXXXXXXX;"
client-option "request subnet-mask, routers, domain-name-servers, domain-name, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, rfc3118-auth, domain-search, SIP, V-I;"
default-route update
default-route-distance 210
global-option "option rfc3118-auth code 90 = string;"
global-option "option SIP code 120 = string;"
global-option "option V-I code 125 = string;"
name-server update
}
egress-qos "0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0"
firewall {
in {
ipv6-name WAN6_IN
name WAN_IN
}
local {
ipv6-name WAN6_LOCAL
name WAN_LOCAL
}
}
ipv6 {
address {
autoconf
}
dup-addr-detect-transmits 1
}
}
vif 838 {
bridge-group {
bridge br0
}
description "eth1.838 (VoD)"
egress-qos "0:4 1:4 2:4 3:4 4:4 5:4 6:4 7:4"
}
vif 840 {
bridge-group {
bridge br1
}
description "eth1.840 (multicast)"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
ethernet eth2 {
description LIVEBOX
duplex auto
speed auto
vif 832 {
address 192.168.2.1/24
description "eth2.832 LIVEBOX"
}
vif 838 {
bridge-group {
bridge br0
}
description "eth2.838 LIVEBOX (VoD)"
egress-qos "0:4 1:4 2:4 3:4 4:4 5:4 6:4 7:4"
}
vif 840 {
bridge-group {
bridge br1
}
description "eth2.840 LIVEBOX (multicast)"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
loopback lo {
}
}
service {
dhcp-server {
disabled false
hostfile-update disable
shared-network-name LAN_HOME {
authoritative enable
subnet 192.168.0.0/24 {
default-router 192.168.0.1
dns-server 192.168.0.1
......
}
}
shared-network-name LIVEBOX {
authoritative enable
subnet 192.168.2.0/24 {
default-router 192.168.2.1
dns-server 81.253.149.6
dns-server 80.10.246.1
lease 86400
start 192.168.2.30 {
stop 192.168.2.50
}
}
}
static-arp disable
use-dnsmasq enable
}
dns {
forwarding {
cache-size 1024
listen-on lo
listen-on eth0.1
listen-on eth0.30
name-server 8.8.8.8
name-server 8.8.4.4
options bogus-priv
options domain-needed
options rebind-localhost-ok
options stop-dns-rebind
options dhcp-option=tag:LIVEBOX,15,orange.fr
options dhcp-option=tag:LIVEBOX,90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
options dhcp-option=tag:LIVEBOX,119,PUT.access.orange-multimedia.net.
options dhcp-option=tag:LIVEBOX,120,00:06:73:62:63:74:33:67:03:50:55:54:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00
options dhcp-option=tag:LIVEBOX,125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
}
}
Et du coup l'ERL génère dans /etc/dnsmasq.conf
#
# autogenerated by vyatta-dns-forwarding.pl on Sat Nov 24 02:08:14 CET 2018
#
log-facility=/var/log/dnsmasq.log
interface=lo
interface=eth0.1
interface=eth0.30
cache-size=1024
server=8.8.8.8 # statically configured
server=8.8.4.4 # statically configured
bogus-priv
domain-needed
rebind-localhost-ok
stop-dns-rebind
dhcp-option=tag:LIVEBOX,15,orange.fr
dhcp-option=tag:LIVEBOX,90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
dhcp-option=tag:LIVEBOX,119,PUT.access.orange-multimedia.net.
dhcp-option=tag:LIVEBOX,120,00:06:73:62:63:74:33:67:03:50:55:54:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00
dhcp-option=tag:LIVEBOX,125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
no-resolv
Et dans /etc/dnsmasq.d/dnsmasq-dhcp-config.conf
#
# autogenerated by /opt/vyatta/sbin/dnsmasq-dhcp-config.pl on Thu Nov 8 01:53:13 CET 2018
#
dhcp-leasefile=/var/run/dnsmasq-dhcp.leases
domain=XXXX.lan
###shared-network LAN_HOME
#subnet 192.168.0.0/24
dhcp-range=set:LANHOME,192.168.0.100,192.168.0.200,255.255.255.0,3600
domain=invitro.lan,192.168.0.0/24,local
dhcp-option=tag:LANHOME,option:domain-name,XXXX.lan
dhcp-option=tag:LANHOME,option:router,192.168.0.1
dhcp-option=tag:LANHOME,option:ntp-server,192.168.0.1
dhcp-option=tag:LANHOME,option:dns-server,192.168.0.1
#static reservations for subnet 192.168.0.0/24
dhcp-host=50:C7:XX:XX:XX:XX,set:LANHOME,192.168.0.XX #IBOZ
host-record=IBOZ.XXXX.lan,192.168.0.XX,3600 #IBOZ.XXXX.lan
.....
#end of subnet 192.168.0.0/24
###end of shared-network LAN_HOME
###shared-network LIVEBOX
#subnet 192.168.2.0/24
interface=eth2.832 #automatically added for this dhcp subnet to work
dhcp-range=set:LIVEBOX,192.168.2.30,192.168.2.50,255.255.255.0,86400
dhcp-option=tag:LIVEBOX,option:router,192.168.2.1
dhcp-option=tag:LIVEBOX,option:dns-server,81.253.149.6,80.10.246.1
#static reservations for subnet 192.168.2.0/24
#end of subnet 192.168.2.0/24
###end of shared-network LIVEBOX
#global settings depending on previous config
dhcp-ttl=1800 #this is half the smallest lease time found
dhcp-fqdn #we have default domain, so we can use dhcp-fqdn
dhcp-authoritative #at least one shared-network was declared authoritative
-
Si si j'utilise le vlan 832 et les DNS orange ... Et oui j'utilise le fix de la LB.
interfaces {
ethernet eth2 {
description LIVEBOX
duplex auto
speed auto
vif 832 {
address 192.168.2.1/24
description "eth2.832 LIVEBOX"
}
service {
dhcp-server {
shared-network-name LIVEBOX {
authoritative enable
subnet 192.168.2.0/24 {
default-router 192.168.2.1
dns-server 81.253.149.6
dns-server 80.10.246.1
lease 86400
start 192.168.2.30 {
stop 192.168.2.50
}
}
}
dns {
forwarding {
cache-size 1024
listen-on lo
listen-on eth0.1
listen-on eth0.30
name-server 8.8.8.8
name-server 8.8.4.4
options bogus-priv
options domain-needed
options rebind-localhost-ok
options stop-dns-rebind
options dhcp-option=tag:LIVEBOX,15,orange.fr
options dhcp-option=tag:LIVEBOX,90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
options dhcp-option=tag:LIVEBOX,119,PUT.access.orange-multimedia.net.
options dhcp-option=tag:LIVEBOX,120,00:06:73:62:63:74:33:67:03:50:55:54:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00
options dhcp-option=tag:LIVEBOX,125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
}
}
[/code]
OK, merci. Ce n'était pas très clair pour moi, car dans la conf /etc/dnsmasq.d/dnsmasq-dhcp-config.conf je ne vois pas les options 15,90,119 pour le réseau Livebox, et dans le fichier /etc/dnsmasq.conf je vois qu'il écoute que sur les interfaces eth0.1 et eth0.30.
Mais à la fin tu as bien dnsmasq comme serveur DHCP sur le réseau eth2.832, donc dnsmasq va prendre sa config tant du fichier /etc/dnsmasq.d/dnsmasq-dhcp-config.conf et /etc/dnsmasq.conf .
-
Oh, ça, ça pu vraiment effectivement :(
Pourquoi il font ça ? Franchement...
(j'imagine que c'est d'un point de vue sécurité évidemment, m'enfin...)
le plaisir d'emm****** le monde... je vois que ca
-
Mhhh dans ce cas il faudrait que la clé privée + certif client soit bien planqué dans le firmware. Mais oui, c'est certain.
ils ont déja essayé ca avec les DVD et les BluRay... ca a pas tenu longtemps ;-)
-
sxpert, toujours aussi constructif, merci.
-
Ces récentes modifications ne concernent que la téléphonie on est d 'accord ? ???
pas de modifications à faire si on n'a pas de config téléphone ?
-
J'ai perdu la connexion ce matin à 3h20. Je ne suis pas à la maison, je ne peux donc pas vérifier pourquoi, mais comme c'est à l'heure du renouvellement du bail, je me demande si Orange commence maintenant à ajouter d'autres modifications. Ou peut-être que c'est juste un problème local.
-
Mon dernier renouvellement de bail date d'hier soir (27/11) à 23h17 et tout est ok.
-
J'ai perdu la connexion ce matin à 3h20. Je ne suis pas à la maison, je ne peux donc pas vérifier pourquoi, mais comme c'est à l'heure du renouvellement du bail, je me demande si Orange commence maintenant à ajouter d'autres modifications. Ou peut-être que c'est juste un problème local.
Rien à signaler pour moi https://debian.ovh/Orange%20VLAN832%20DHCP%20%28DEBIAN%29/
-
J'ai perdu la connexion ce matin à 3h20. Je ne suis pas à la maison, je ne peux donc pas vérifier pourquoi, mais comme c'est à l'heure du renouvellement du bail, je me demande si Orange commence maintenant à ajouter d'autres modifications. Ou peut-être que c'est juste un problème local.
Pareil. Le renouvellement DHCPv6 s´est bien passé vers 02:40. Puis connexion perdue vers 03:30 ce matin (je le sais d´après les tentatives d´intrusions dans les logs du firewall). Ca ne semble pas relié à DHCP, car le renouvellement DHCPv4 aurait du être vers 11h00 ce matin.
Update (19:16): en tuant et relancant dhclient, j'ai obtenu un nouveau lease, et cette fois la connexion à internet fonctionne. Pareil en IPv6.
-
Hello!
Tout pareil : j'ai perdu ma connexion à 03:23:07 (dernier drop iptables à 03:23:06 et inactivity timeout d'OpenVPN à 03:24:07). La chose n'est pas corrélée avec un événement DHCPv4. J'ai retrouvé ma connexion après avoir redémarré l'ONT (c'était probablement inutile, les stats affichées par son interface web étaient ok) et après avoir relancé dhclient.
By the way, petit effet de bord d'utiliser un hash random : j'ai remarqué qu'avant redémarrage, dhclient avait beaucoup plus de baux dans /var/lib/dhcp/dhclient.leases (une vingtaine au lieu de deux je dirais).
-
Bonjour Tout monde,
J'ai un petit problème avec ma conf pour ma livebox UHD je viens de recevoir...
Je n'arrive pas à la faire fonctionner est ce quelqu'un aura une petite idée
Voici les paramètres que j’envoie merci pour votre aide...
ethernet eth1 {
description "Arrivee Fibre WAN"
duplex auto
speed auto
vif 832 {
address dhcp
description "Arrivee Internet Orange"
dhcp-options {
global-option "option rfc3118-auth code 90 = string;"
client-option "send vendor-class-identifier "sagem";"
client-option "send dhcp-client-identifier 1:48:xx:xx:xx:xx:xx;" >>>> MAC LIVEBOX 4
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox4";"
client-option "send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1A:09:xx:00:xx:58:01:03:41:01:xx:xx:74:69:xx:6b:32:xx:67:72:79:66:3C:xx:xx:xx:xx:35:35:61:36:63:65:39:xx:xx:xx:xx:xx:39:03:13:30:25:xx:xx:xx:xx:5d:0b:92:2a:cc:xx:xxx:xx:xx:xx:xx;" >>>Generer avec le script de ZOC
client-option "request subnet-mask, routers, domain-name-servers, domain-name, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, rfc3118-auth;"
default-route update
default-route-distance 210
name-server update
}
egress-qos "0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0"
firewall {
in {
ipv6-name WANv6_IN
name WAN_IN
}
local {
ipv6-name WANv6_LOCAL
name WAN_LOCAL
}
out {
ipv6-name WANv6_OUT
name WAN_OUT
}
}
ipv6 {
address {
autoconf
}
dup-addr-detect-transmits 1
}
}
vif 838 {
address dhcp
description "VLAN TV Replay VOD"
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\047FSVDSL_livebox.MLTV.softathome.Livebox4";"
client-option "send dhcp-client-identifier 1:18:9A:xx:xx:xx:xx;" >>>>> MAC PETITE BOX UHD
client-option "request subnet-mask, routers, rfc3442-classless-static-routes;"
default-route no-update
default-route-distance 210
name-server update
}
egress-qos "0:4 1:4 2:4 3:4 4:4 5:4 6:4 7:4"
}
vif 840 {
address 192.168.255.254/24
description "VLAN TV Multicast"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
ethernet eth2 {
address 192.168.88.254/24
description "Decodeur Livebox"
duplex auto
speed auto
}
loopback lo {
}
}
protocols {
igmp-proxy {
disable-quickleave
interface eth0 {
role disabled
threshold 1
}
interface eth1 {
role disabled
threshold 1
}
interface eth1.832 {
role disabled
threshold 1
}
interface eth1.838 {
role disabled
threshold 1
}
interface eth1.840 {
alt-subnet 0.0.0.0/0
role upstream
threshold 1
}
interface eth2 {
alt-subnet 0.0.0.0/0
role downstream
threshold 1
}
}
}
service {
dhcp-server {
disabled false
global-parameters "option rfc3118-auth code 90 = string;"
global-parameters "option SIP code 120 = string;"
global-parameters "option Vendor-specific code 125 = string;"
hostfile-update disable
shared-network-name "DHCP_LAN" {
authoritative enable
subnet 192.168.77.0/24 {
default-router 192.168.77.254
dns-server 192.168.77.254
lease 86400
ntp-server 192.168.77.254
start 192.168.77.10 {
stop 192.168.77.200
}
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;"
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
subnet-parameters "option domain-search "NIC.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
}
}
}
shared-network-name LAN_ETH2_TV {
authoritative enable
subnet 192.168.88.0/24 {
default-router 192.168.88.254
dns-server 80.10.246.3
dns-server 81.253.149.10
lease 86400
ntp-server 192.168.88.254
start 192.168.88.10 {
stop 192.168.88.10
}
static-mapping LAN_ETH2_TV {
ip-address 192.168.88.10
mac-address xx:xx:xx:xx:xx:xx >>> MAC BOX UHD
static-mapping-parameters "option domain-name-servers 80.10.246.3,81.253.149.10;"
static-mapping-parameters "option Vendor-specific 00:00:0d:e9:24:04:06:YY:YY:YY:YY:YY:YY:05:0f:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:06:09:4c:69:76:65:62:6f:78:20:34;"
YY:YY:YY ( 3 premier octet de la livebox en hexa)
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX (Numero de serie de box UHD en hexa)
34 à la fin ( V4 en hexa pour livebox 4 ::))
Merci pour votre aide
-
- Il ne faut pas changer l'adresse Mac dans la config du VLAN 838. C'est la Mac de la Livebox qui est sensée y être, pas celle du décodeur
- Pour le décodeur UHD, ton serveur DHCP est sensé envoyer une option supplèmentaire (125), c'est décrit ici: https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/msg583577/#msg583577 (message initial et les suivants)
Accessoirement, le VLAN 838 ne sert plus à rien, tu peux l'enlever (ou éventuellement mettre le vif 838 à "disable" si tu veux pouvoir revenir en arrière rapidement). Replay et VOD passent maintenant par le 832 comme la téléphonie et internet.
Edit: Le script que j'ai utilisé pour générer mon option 125:
#!/bin/bash
maclivebox=24:7F:20:XX:XX:XX
verlivebox=4
serlivebox=LK12345XX123456
tohex() {
for h in $(echo $1 | sed "s/\(.\)/\1 /g"); do printf %02x \'$h; done
}
addsep() {
echo $(echo $1 | sed "s/\(..\)/:\1/g")
}
m=0406$(tohex ${maclivebox//:/} | cut -c1-12)
s=050f$(tohex ${serlivebox})
l=0609$(tohex Livebox)20$(tohex $verlivebox)
echo 00:00:0d:e9:24$(addsep ${m}${s}${l})
-
Merci ZOC tu es au top je teste ce soir ;)
-
D'ailleurs ZOC comme tu es sur Antibes aussi :-) Est ce que tu as constaté une forte baisse de débit chez toi?
-
D'ailleurs ZOC comme tu es sur Antibes aussi :-) Est ce que tu as constaté une forte baisse de débit chez toi?
J'ai vu ton post, et en ce qui me concerne, non, pas de baisse de débit.
-
- Il ne faut pas changer l'adresse Mac dans la config du VLAN 838. C'est la Mac de la Livebox qui est sensée y être, pas celle du décodeur
- Pour le décodeur UHD, ton serveur DHCP est sensé envoyer une option supplèmentaire (125), c'est décrit ici: https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/msg583577/#msg583577 (message initial et les suivants)
Accessoirement, le VLAN 838 ne sert plus à rien, tu peux l'enlever (ou éventuellement mettre le vif 838 à "disable" si tu veux pouvoir revenir en arrière rapidement). Replay et VOD passent maintenant par le 832 comme la téléphonie et internet.
Edit: Le script que j'ai utilisé pour générer mon option 125:
#!/bin/bash
maclivebox=24:7F:20:XX:XX:XX
verlivebox=4
serlivebox=LK12345XX123456
tohex() {
for h in $(echo $1 | sed "s/\(.\)/\1 /g"); do printf %02x \'$h; done
}
addsep() {
echo $(echo $1 | sed "s/\(..\)/:\1/g")
}
m=0406$(tohex ${maclivebox//:/} | cut -c1-12)
s=050f$(tohex ${serlivebox})
l=0609$(tohex Livebox)20$(tohex $verlivebox)
echo 00:00:0d:e9:24$(addsep ${m}${s}${l})
Bon je ne sais pas pourquoi mon ERL n'accepte pas ma config
shared-network-name LAN_ETH2_TV
...
Est-ce qu'il y a quelques choses qui a changé dans dans la version 1.10 ( je ne vois rien dans le changelog) parceque j'en avais profité pour mettre a jour ...
-
shared-network-name VLAN_TVIP_DHCP {
authoritative enable
subnet 192.168.68.0/24 {
default-router 192.168.68.1
dns-server 192.168.68.1
lease 86400
ntp-server 192.168.68.1
start 192.168.68.100 {
stop 192.168.68.200
}
static-mapping TVChambre {
ip-address 192.168.68.102
mac-address 10:77:b1:xx:xx:xx
static-mapping-parameters "option Vendor-specific 00:00:0d:e9:24:04:06:32:34:37:46:32:30:05:0f:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:06:09:4c:69:76:65:62:6f:78:20:34;"
}
static-mapping TVSalon {
ip-address 192.168.68.101
mac-address 24:7f:20:xx:xx:xx
static-mapping-parameters "option Vendor-specific 00:00:0d:e9:24:04:06:32:34:37:46:32:30:05:0f:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:06:09:4c:69:76:65:62:6f:78:20:34;"
}
}
}
-
shared-network-name VLAN_TVIP_DHCP {
authoritative enable
subnet 192.168.68.0/24 {
default-router 192.168.68.1
dns-server 192.168.68.1
lease 86400
ntp-server 192.168.68.1
start 192.168.68.100 {
stop 192.168.68.200
}
static-mapping TVChambre {
ip-address 192.168.68.102
mac-address 10:77:b1:xx:xx:xx
static-mapping-parameters "option Vendor-specific 00:00:0d:e9:24:04:06:32:34:37:46:32:30:05:0f:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:06:09:4c:69:76:65:62:6f:78:20:34;"
}
static-mapping TVSalon {
ip-address 192.168.68.101
mac-address 24:7f:20:xx:xx:xx
static-mapping-parameters "option Vendor-specific 00:00:0d:e9:24:04:06:32:34:37:46:32:30:05:0f:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:06:09:4c:69:76:65:62:6f:78:20:34;"
}
}
}
Nouveau problème
-
Le contenu de ton option "Vendor-specific" n'est pas bon.
-
Le contenu de ton option "Vendor-specific" n'est pas bon.
Ok je regarde merci encore
-
J'ai perdu la connexion ce matin à 3h20. Je ne suis pas à la maison, je ne peux donc pas vérifier pourquoi, mais comme c'est à l'heure du renouvellement du bail, je me demande si Orange commence maintenant à ajouter d'autres modifications. Ou peut-être que c'est juste un problème local.
Bien après un peu plus de 48 heures de non-réactivité, mon système s'est reconnecté. Je ne suis toujours pas parti, je ne peux donc pas vraiment vérifier beaucoup de choses, mais en utilisant un VPN et en parcourant les journaux, il semble qu'Orange ne répondait tout simplement pas à la demande dhclient.
-
Bonjour,
Je viens de m'apercevoir que je n'avais plus de téléphone (78). Il semblerait que vous parliez de modifier des paramètres mais je m'y perd un peu.
Pourriez vous m'indiquer s'il faut rajouter comme chez Zoc:
subnet-parameters "option domain-search "NIC.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
et changer la partie NIC?
Si ou comment trouver mon bon nom de domaine par rapport à mon site svp?
Merci.
-
Hello,
Après 2/3 semaines avec des débits plafonnant à 100 M (Up/DL) ... j'ai eu le temps de faire un full hard reset de la box.
J'ai maintenant le comportement suivant :
- hard reset box, connectée sur l'ONT : plus de limite de débit
- je branche l'ERL ... boum : 100M
- je teste le débit sur la box connectée à l'ONT : 100 M
J'ai remarqué que ":sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh" change à chaque fois maintenant ... il suffit que je débranche le câble de la box pour la passer sur l'ERL, que je passe l'ONT sur l'ERL ... et voilà, modif.
Etant donné qu'un full reset de la box permet de récup le débit max, c'est logiquement l'ERL qui est en cause. :-\
Voici ma config pour référence !
interfaces {
bridge br0 {
aging 300
bridged-conntrack disable
description "bro -> eth2.838 LIVEBOX (VoD)"
hello-time 2
max-age 20
priority 0
promiscuous disable
stp false
}
bridge br1 {
aging 300
bridged-conntrack disable
description "br1 -> eth2.840 LIVEBOX (ZAPPING + CANAL 1)"
hello-time 2
max-age 20
priority 0
promiscuous disable
stp false
}
ethernet eth0 {
address 192.168.1.1/24
description LAN_HOME_ETH0
duplex auto
speed auto
vif 150 {
address 192.168.150.1/24
description LAN_IoT
}
}
ethernet eth1 {
description "eth1 ONT (FIBRE RJ45)"
duplex auto
speed auto
vif 832 {
address dhcp
description "eth1.832 (INTERNET + VOIP + CANAL 2)"
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox3";"
client-option "send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;"
client-option "request subnet-mask, routers, domain-name-servers, domain-name, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, rfc3118-auth;"
default-route update
default-route-distance 210
global-option "option rfc3118-auth code 90 = string;"
name-server update
}
egress-qos "0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0"
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
ipv6 {
address {
autoconf
}
dup-addr-detect-transmits 1
}
}
vif 838 {
bridge-group {
bridge br0
}
description "eth1.838 (VoD)"
egress-qos "0:4 1:4 2:4 3:4 4:4 5:4 6:4 7:4"
}
vif 840 {
bridge-group {
bridge br1
}
description "eth1.840 (ZAPPING + CANAL 1)"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
ethernet eth2 {
description LAN_BOX_ETH2
duplex auto
speed auto
vif 832 {
address 192.168.2.1/24
description "eth2.832 LIVEBOX (INTERNET + VOIP + CANAL 2)"
}
vif 838 {
bridge-group {
bridge br0
}
description "eth2.838 LIVEBOX (VoD)"
egress-qos "0:4 1:4 2:4 3:4 4:4 5:4 6:4 7:4"
}
vif 840 {
bridge-group {
bridge br1
}
description "eth2.840 LIVEBOX (ZAPPING + CANAL 1)"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
loopback lo {
}
}
-
J'ai remarqué que ":sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh" change à chaque fois maintenant ...
C'est comme ça depuis la mise en place du nouveau format de l'option...
Bon, sinon, la box envoie également sa mac address depuis un petit moment. A voir si ça change quelque chose au débit (je n'ai pas de problème personnellement avec mon ER4 mais j'envoie la mac depuis que l'option 90 a changée):
client-option "send dhcp-client-identifier 1:24:7f:20:XX:XX:XX;"
-
J’ai pas de limite de débit avec les options qui avaient été données au début du sujet. Par contre, depuis quelques temps, je suis limité à 10 Mbps en up sur le ssh. J’ai pas tenté de le faire passer par un autre port pour voir, mais en tout cas en NFS vers le même serveur je monte au max.
-
Pas de souci avec mon Edgerouter4:
(https://www.speedtest.net/result/7864385051.png)(https://www.speedtest.net/result/7864393871.png)
-
Voici ma config pour référence !
interfaces {
bridge br0 {
aging 300
bridged-conntrack disable
description "bro -> eth2.838 LIVEBOX (VoD)"
hello-time 2
max-age 20
priority 0
promiscuous disable
stp false
}
bridge br1 {
aging 300
bridged-conntrack disable
description "br1 -> eth2.840 LIVEBOX (ZAPPING + CANAL 1)"
hello-time 2
max-age 20
priority 0
promiscuous disable
stp false
}
ethernet eth0 {
address 192.168.1.1/24
description LAN_HOME_ETH0
duplex auto
speed auto
vif 150 {
address 192.168.150.1/24
description LAN_IoT
}
}
ethernet eth1 {
description "eth1 ONT (FIBRE RJ45)"
duplex auto
speed auto
vif 832 {
address dhcp
description "eth1.832 (INTERNET + VOIP + CANAL 2)"
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox3";"
client-option "send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;"
client-option "request subnet-mask, routers, domain-name-servers, domain-name, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, rfc3118-auth;"
default-route update
default-route-distance 210
global-option "option rfc3118-auth code 90 = string;"
name-server update
}
egress-qos "0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0"
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
ipv6 {
address {
autoconf
}
dup-addr-detect-transmits 1
}
}
vif 838 {
bridge-group {
bridge br0
}
description "eth1.838 (VoD)"
egress-qos "0:4 1:4 2:4 3:4 4:4 5:4 6:4 7:4"
}
vif 840 {
bridge-group {
bridge br1
}
description "eth1.840 (ZAPPING + CANAL 1)"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
ethernet eth2 {
description LAN_BOX_ETH2
duplex auto
speed auto
vif 832 {
address 192.168.2.1/24
description "eth2.832 LIVEBOX (INTERNET + VOIP + CANAL 2)"
}
vif 838 {
bridge-group {
bridge br0
}
description "eth2.838 LIVEBOX (VoD)"
egress-qos "0:4 1:4 2:4 3:4 4:4 5:4 6:4 7:4"
}
vif 840 {
bridge-group {
bridge br1
}
description "eth2.840 LIVEBOX (ZAPPING + CANAL 1)"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
loopback lo {
}
}
Sûrement un effet du bridge défini dans le fichier de config, il semblerait que le bridge tue les perfs des routeurs Ubiquiti (dont l'ERL). En effet avec un bridge, il n'y a plus d'offloading.
https://community.ubnt.com/t5/EdgeRouter/Interface-Bridging-Performance-Impact/td-p/2494504 (https://community.ubnt.com/t5/EdgeRouter/Interface-Bridging-Performance-Impact/td-p/2494504)
Le mieux est de NATer le VLAN 832 et l'utiliser igmp-proxy sur le VLAN 840 pour le TV (les autres VLANs sont inutiles)
Comme cela tout le routage internet est coté HW (offloading) et pas coté SW (la CPU sature). Avec ce type de config mon USG me donne le débit max sans aucune dégradation dans le temps.
-
Non mais là son bridge est sur eth2 qui est dédié à la box. L'offload n'est donc pas désactivé sur le VLAN 832 et sur l'interface eth0 qui représente son LAN.
On a tous utilisé cette solution du bridge au début pour la TV+téléphonie à travers la box et ça n'a jamais limité le débit.
-
Hello,
Du coup en mettant l'adresse de la zone du 92 (PUT), le téléphone est revenu. Cela doit être la même adresse que celle du 78 j'imagine :).
Mais je suis toutjour preneur de la technique de wireshark pour récupérer les informations ou m'indiquer un bon tuto avec la config livebox.
Merci et bonne journée.
Schuss
-
Pourriez vous m'indiquer s'il faut rajouter comme chez Zoc:
Si tu as un routeur de chez Ubiquiti c'est facile: Le client DHCP du routeur loggue les baux qu'il obtient dans /run. En l'occurrence chez moi dans /run/dhclient_eth1_832.leases (eth1 est l'interface qui va à l'ONT). Il suffit juste de recopier ce qui nous intéresse dans la configuration du serveur DHCP. Même pas besoin de wireshark.
-
Merci Zoc. Je ne le savais pas :)
Du coup c'est VEL :)
Bon dimanche.
Schusss
-
Pas de souci avec mon Edgerouter4:
(https://www.speedtest.net/result/7864385051.png)(https://www.speedtest.net/result/7864393871.png)
J’ai pas de souci non plus en HTTPS.
-
C'est comme ça depuis la mise en place du nouveau format de l'option...
Bon, sinon, la box envoie également sa mac address depuis un petit moment. A voir si ça change quelque chose au débit (je n'ai pas de problème personnellement avec mon ER4 mais j'envoie la mac depuis que l'option 90 a changée):
client-option "send dhcp-client-identifier 1:24:7f:20:XX:XX:XX;"
Merci Zoc, je vais rajouter cela et vous faire un retour !
Bonne journée à tous :)
-
Non mais là son bridge est sur eth2 qui est dédié à la box. L'offload n'est donc pas désactivé sur le VLAN 832 et sur l'interface eth0 qui représente son LAN.
On a tous utilisé cette solution du bridge au début pour la TV+téléphonie à travers la box et ça n'a jamais limité le débit.
Je confirme ... j'utilise cette config depuis un moment et je n'ai jamais eu de mal à atteindre un 900/300.
Elle a même marché quelques temps comme une grande jusqu'à effondrement des perf il y a 1 mois (environ je ne teste pas mon débit tous les jours).
-
@topvad, je rencontre la même limitation de débit depuis environ 1 mois, sans solution à ce jour. J'ai modifié la configuration DHCP avec les dernières options en date (erl3 avec les 2 bridge + livebox pour TV et tel), sans résultat. J'évoque les actions ici: https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/msg599068/#msg599068 et là: https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/msg601744/#msg601744
Tous les services sont fonctionnels et il n'y a aucune coupure.
@All
J'ai le sentiment que ce c'est le décodeur TV qui conditionne le débit 900/300 et que ce dernier ne communique plus complètement avec Orange dans cette configuration. La limitation de débit est la même avec la livebox seule directement sur l'ONT. La mise sous tension du décodeur entraîne un reboot de la livebox qui retrouve alors le débit 900/300.
Je me suis aperçu initialement de la perte de débit consécutivement à l'arrêt du décodeur TV (interrupteur sur off). Le ventilateur vrombissait sans arrêt alors qu'il était en veille. Le bruit de turbien n'arrivait jamais précédemment. C'est arrivé une ou 2 fois depuis.
konki
-
J'ai le sentiment que ce c'est le décodeur TV qui conditionne le débit 900/300
Franchement je ne vois absolument pas le rapport...
-
Bonjour
je n'ai plus de téléphone,
Zoc peux tu me confirmer , que je dois rajouter ces deux lignes dans mon config.boot de mon erl3 afin de retrouver la ligne téléphonique .
subnet-parameters "option domain-search "NIC.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
la phrase comporte des " " " est ce normal ?
merci de ton retour .
vlsoft
-
Les " c'est normal oui.
Par contre, non, ce n'est pas obligatoirement ce qu'il faut rajouter: le "NIC" marche pour moi parce que je suis dans la région de Nice. A adapter donc selon le lieu de résidence et je ne connais pas tous les codes disponibles.
-
comment savoir le nom de code de sa ville. PUT pour Puteaux moi je suis à sevres ..
Domain search : PUT.access.orange-multimedia.net
SIP : sbct3g.PUT.access.orange-multimedia.net
Merci de votre aide.
-
Bon, reprenons ;) :
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg596704/#msg596704
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg602326/#msg602326
-
Merci Zoc .
j'ai bien lu les différents post , j'ai bien suivi les posts et j'ai rajouter les options .
Tous fonctionne bien sauf le téléphone depuis 1 semaine- en raison de la nouvelle norme.
il me manque l'option XXX.access.orange-multimedia.net . mais je ne sais pas quoi mettre dans les XXX , je ne connais pas le code de mon lieu de résidence.
voici ma config .
shared-network-name LIVEBOX {
authoritative enable
subnet 192.168.4.0/24 {
default-router 192.168.4.1
dns-server 81.253.149.9
dns-server 80.10.246.1
domain-name orange.fr
lease 86400
start 192.168.4.30 {
stop 192.168.4.50
}
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;"
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:41:55:42:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:00:00:00:00:ff:ff:ff:ff:ff;"
}
}
-
il me manque l'option XXX.access.orange-multimedia.net . mais je ne sais pas quoi mettre dans les XXX , je ne connais pas le code de mon lieu de résidence.
Le second lien explique comment trouver XXX...
-
ok super merci.
Merci pour l'info , je suis passé à coté .
je suis sur PUT ( option domain-search "PUT.access.orange-multimedia.net.";)
donc je rajoute :
subnet-parameters "option domain-search "PUT.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
-
@topvad, je rencontre la même limitation de débit depuis environ 1 mois, sans solution à ce jour. J'ai modifié la configuration DHCP avec les dernières options en date (erl3 avec les 2 bridge + livebox pour TV et tel), sans résultat. J'évoque les actions ici: https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/msg599068/#msg599068 et là: https://lafibre.info/remplacer-livebox/en-cours-remplacer-sa-livebox-par-un-routeur-ubiquiti-edgemax/msg601744/#msg601744
Tous les services sont fonctionnels et il n'y a aucune coupure.
@All
J'ai le sentiment que ce c'est le décodeur TV qui conditionne le débit 900/300 et que ce dernier ne communique plus complètement avec Orange dans cette configuration. La limitation de débit est la même avec la livebox seule directement sur l'ONT. La mise sous tension du décodeur entraîne un reboot de la livebox qui retrouve alors le débit 900/300.
Je me suis aperçu initialement de la perte de débit consécutivement à l'arrêt du décodeur TV (interrupteur sur off). Le ventilateur vrombissait sans arrêt alors qu'il était en veille. Le bruit de turbien n'arrivait jamais précédemment. C'est arrivé une ou 2 fois depuis.
konki
Moi aussi j'ai constaté de temps en temps une perte de débit, qui rentre dans l'ordre en général en rebootant tout.
Cependant ça devenait plus fréquent depuis le changement de l'option 90.
Mais en relisant le fil de discussion je me suis rendu compte que je ne passais pas l'option dhcp-client-identifier avec la MAC de ma livebox.
client-option "send dhcp-client-identifier 1:XX:XX:XX:XX:XX:XX;"Faut bien penser à mettre le 1 devant la MAC de la livebox si tu veut que ça fonctionne.
J'ai fais le changement depuis 4 jours on va voir si ça tient dans le temps mais pour l'instant de je suis toujours a 900/300.
Et je viens de me rendre compte que j'avais laissé le décodeur TV éteins depuis l'autre jour ... donc a priori il n'a aucune incidence sur le débit.
-
Je vous confirme que le décodeur n'a rien a voir dans l'histoire, je suis en phase de test sur mon installation, et je n'ai pas encore raccordé le décodeur TV, et j'ai pourtant bien un débit 900/300.
-
Bonsoir,
je n'ai pas fait de nouveaux essais avec la Livebox seule mais je reste limité à 100/100 (iperf3) sur le routeur avec ou sans la livebox derrière.
La configuration du serveur DHCP comporte bien tous les éléments de /run/dhclient_eth1_832.leases, HORMIS option dhcp-message-type 5; (Acknowledgment message (DHCPAck) )
lease {
interface "eth1.832";
fixed-address XXX.XXX.XXX.XXX;
option subnet-mask 255.255.248.0;
option routers 90.92.160.1;
option dhcp-lease-time 259200;
option dhcp-message-type 5;
option domain-name-servers 81.253.149.9,80.10.246.1;
option dhcp-server-identifier 80.10.247.176;
option domain-search "MSR.access.orange-multimedia.net.";
option unknown-120 0:6:73:62:63:74:33:67:3:4d:53:52:6:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:3:6e:65:74:0;
option dhcp-renewal-time 84600;
option rfc3118-auth 0:0:0:0:0:0:0:0:0:0:0:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;
option broadcast-address 90.92.167.255;
option dhcp-rebinding-time 207400;
option domain-name "orange.fr";
option vendor.unknown-1368 1:a:0:1:0:0:0:ff:ff:ff:ff:ff;
est-ce implicite dans la configuration de eth1_832, ou une nouvelle option?
konki
-
je reste limité à 100/100
vérifier le cable entre l'ONT et l'ERL.
Jerem
-
Hello :)
Plus d'IPV6 pour moi depuis je ne sais pas quand hélas
2018.12.18 02:56:13 Client Info Processing msg (SOLICIT,transID=0xabcd94,opts: 1 25 8 16 15 11 11 6)
2018.12.18 02:56:13 Client Error AUTH: protocol 9337584 not supported yet.
root@router:/run# dibbler-client status
| Dibbler - a portable DHCPv6, version 1.0.1 (CLIENT, Linux port)
| Authors : Tomasz Mrugalski<thomson(at)klub.com.pl>,Marek Senderski<msend(at)o2.pl>
| Licence : GNU GPL v2 only. Developed at Gdansk University of Technology.
| Homepage: http://klub.com.pl/dhcpv6/
Dibbler server: NOT RUNNING.
Dibbler client: RUNNING, pid=6241
Dibbler relay : NOT RUNNING.
et j'ai bien adapté l'option 11
iface eth1.832 {
pd
option 16 hex 00:00:04:0e:00:05:73:61:67:65:6d
option 15 hex 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:34
option 11 hex 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
option 11 hex 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
option dns-server
}
J'ai purgé dibbler et réinstallé mais rien n'y fait
Je sèche du coup... des idées ?
-
et j'ai bien adapté l'option 11
Tu utilises la version tronquée de l'option 11. Essaye avec la vraie option 11, celle qui contient le mot de passe encodé façon PPP CHAP...
A mon avis Orange doit commencer à le vérifier, et du coup ça ne devrait pas tarder à être la même chose pour l'option 90...
-
Bonjour,
J'ai également perdu mon IPv6 (routeur OPNsense), j'ai essayé la version longue de l'option 11 mais ça ne change rien.
En parcourant les logs voici ce que j'ai trouvé :
Dec 17 20:07:35 P-D1-OPNSENSE1 dhcpd: RTSOLD script - Starting dhcp6 client for interface wan(bge1)
Dec 17 20:07:35 P-D1-OPNSENSE1 dhcp6c[27426]: DUID file corrupted
Dec 17 20:07:35 P-D1-OPNSENSE1 dhcp6c[27426]: failed to get a DUID
-
Ouais bin du coup le DUID corrompu c'est pas la faute d'Orange mais du routeur. Sans DUID impossible de faire une requête DHCP6.
-
@zoc D'accord, je cherche côté routeur...
-
Ouais bin du coup le DUID corrompu c'est pas la faute d'Orange mais du routeur. Sans DUID impossible de faire une requête DHCP6.
Ça ne pourrait être la même chose sur l'ERL3 ?
-
Les 2 routeurs ayant des clients DHCP6 différents (dhcp6c sur OpnSense et sans doute dibbler sur ton ELR), la coïncidence serait troublante (et très improbable), d'autant plus que le DUID est un identifiant local qui n'est jamais modifié par le client DHCP6 (hormis pour sa création quand il n'existe pas).
-
Les 2 routeurs ayant des clients DHCP6 différents (dhcp6c sur OpnSense et sans doute dibbler sur ton ELR), la coïncidence serait troublante (et très improbable), d'autant plus que le DUID est un identifiant local qui n'est jamais modifié par le client DHCP6 (hormis pour sa création quand il n'existe pas).
Je fais confiance dans ton analyse.
Comment vérifier du coup que je ne suis pas un boulet et que j'aurais pas inadvertance touche a ça ?
Besoin de log détaillé ou d'autres choses ?
Du coup je vais aussi devoir sniffer pour avoir la chaîne d'authentification complète des fois que...
-
Pour dibbler, le DUID est dans /var/lib/dibbler/client-duid et contient un truc qui ressemble à une adresse mac en plus long (normal, il est déterminé à partir de la mac). En l'occurrence chez moi le DUID est: 00:03:00:01:AdresseMacEth1.
-
Pour dibbler, le DUID est dans /var/lib/dibbler/client-duid et contient un truc qui ressemble à une adresse mac en plus long (normal, il est déterminé à partir de la mac). En l'occurrence chez moi le DUID est: 00:03:00:01:AdresseMacEth1.
J'ai bien une chaîne comme toi.
Plus qu'à sniffer l'authentification original de la livebox pour avoir mon option 11 entière #bienRelou
-
Ouais bin du coup le DUID corrompu c'est pas la faute d'Orange mais du routeur. Sans DUID impossible de faire une requête DHCP6.
Mon IPv6 est revenu, il s'agissait bien de mon DUID qui a sauté après la dernière màj d'OPENsense. J'ai re-généré un DUID de type LLT, si ça peut aider.
-
Re les amis,
Si qqn peut expliquer rapidement comment sniffer le traffic de l'ONT histoire de récupérer ?
On doit le faire depuis l'ERL avec la commande monitor c'est ça ?
Quelques explications ne seraient pas de refus :)
En général je me place sur le switch avec un port mirror mais là vu que tout se passe sur le routeur :/
-
@computman
Pour récupérer ton option 11 en hexa, il faut écouter le port WAN de la Livebox. Pour ma part, je me suis branché en direct et j'ai utilisé Wireshark pour capturer. L'option se trouve dans les trames DHCP.
-
@computman
Pour récupérer ton option 11 en hexa, il faut écouter le port WAN de la Livebox. Pour ma part, je me suis branché en direct et j'ai utilisé Wireshark pour capturer. L'option se trouve dans les trames DHCP.
Merci, donc ONT dans la cage SFP, port WAN cuivre sur mon pc en écoute et ça fonctionne ? La Livebox duplique les flux entre cuivre et Fibre ?
-
Tu n'as pas besoin de l'ONT du tout...
Ce que tu veux sniffer, c'est ce que la box envoie, pas ce qu'elle recoit... Qu'il y ait un ONT ou pas, la box enverra ses requêtes DHCP et ce qui est intéressant est à l'intérieur. Donc dans ton cas: ONT non connecté à la box, PC + wireshark sur le port Ethernet WAN, lancer la capture, démarrer la box, attendre, analyser....
-
Tu n'as pas besoin de l'ONT du tout...
Ce que tu veux sniffer, c'est ce que la box envoie, pas ce qu'elle recoit... Qu'il y ait un ONT ou pas, la box enverra ses requêtes DHCP et ce qui est intéressant est à l'intérieur. Donc dans ton cas: ONT non connecté à la box, PC + wireshark sur le port Ethernet WAN, lancer la capture, démarrer la box, attendre, analyser....
Super merci
Je pensais qu'il fallait analyser toute la communication
@zoc toujours efficace 😉
-
Tu n'as pas besoin de l'ONT du tout...
Ce que tu veux sniffer, c'est ce que la box envoie, pas ce qu'elle recoit... Qu'il y ait un ONT ou pas, la box enverra ses requêtes DHCP et ce qui est intéressant est à l'intérieur. Donc dans ton cas: ONT non connecté à la box, PC + wireshark sur le port Ethernet WAN, lancer la capture, démarrer la box, attendre, analyser....
rien n'y fait :'(
Toujours pas d'IPV6 malgré une option 11 longue (contre une pas longue en IPV4)
(https://i.ibb.co/s3GxjVH/2018-12-19-09-55-46-Clipboard.png) (https://ibb.co/q1fqBr5)
En même temps je me dis que je devrais peut-être rebrancher la BOX pour qu'elle se mette à jour
-
Je viens de rebrancher ma BOX,
Je n'ai pas eu de mise à jour de firmware mais maintenant mon IPV6 refonctionne avec l'ERL sans rien changer (et je n'ai pas changé d'IP)
Donc après branchement de la BOX, quand j'ai rebranché l'ERL sans le reboot il recevait des réponses qu'il ne recevait pas avant
La BOX à du faire qqch pour que le serveur DHCP réponde à nouveau
(https://i.ibb.co/MVRdmP4/2018-12-19-10-43-46-Clipboard.png) (https://ibb.co/Kq9nJVk)
Si ça peut aider pour de futur troubleshoot
-
J'ai reconfiguré certains commutateurs réseau et éteint mon routeur (OPNsense) pendant un moment. Lorsque j'ai redémarré, j'ai reçu une adresse IPv4 mais pas IPv6. Rien n'avait changé. J'ai décidé de connecter ma livebox. Il a IPv4 et IPv6. REMARQUE: L'adresse IPv4 a été modifiée par rapport à celle de mon routeur, mais le préfixe IPv6 est resté inchangé. J'ai reconnecté mon routeur. Il a la même nouvelle adresse IPv4 que la Livebox mais pas encore IPv6. J'ai donc capturé l'application Livebox Dhcp6c. Cela ressemblait exactement à celui créé par mon routeur. L'option d'authentification 11 avait la même longueur, mais la chaîne était évidemment différente car il s'agissait d'une chaîne SALT HASH. Alors j'ai pris cette nouvelle chaîne et l'appliqué à mon routeur et IPv6 est retourné. Je ne sais pas pourquoi c'est arrivé autrement que parce qu'il y a un hash construit en utilisant l'adresse IPv4?
-
J'utilise exactement la même chaine d'authentification pour IPv4 et IPv6 (obtenue en sniffant les paquest DHCP IPv4) et j'ai toujours mon adresse IPv4 et mon préfixe IPv6.
-
Mais avez-vous changé d'adresse IPv4? J'avais le même avant que l'IPv4 change.
-
Non, mais je doute fortement (et je n'ai aucune information allant dans ce sens, au contraire d'ailleurs) que le hash ne soit pas aléatoire.
D'une part ça ne sert à rien (le seul but d'Orange avec cette nouvelle chaine d'authentification, c'est d'identifier le client par un moyen plus sûr que le simple login, qui peut facilement se retrouver copié/collé dans un forum par erreur).
D'autre part, ça nécessiterait de la Livebox fasse d'abord une requête DHCP en IPv4 puis ensuite, uniquement en cas de succès, génère un hash pour DHCP6, ce qui n'est absolument pas ce que fait la box: Elle n'attend pas d'avoir une réponse DHCP4 pour faire du DHCP6.
Enfin, ça complexifierai l'authentification du coté des proxies DHCP chez Orange qui autorisent l'accès pour aucun bénéfice sauf 'emmerder le client'. Sachant qu'Orange a abandonné sa solution d'accès développée en interne en Octobre 2017 (PFA: http://www.focom-orange.fr/arret-projet-plate-forme-dacces ) pour passer sur un truc vendu clés en main par HP (si ma mémoire est bonne), je ne les vois pas faire un développement spécifique pour mettre en place ce truc sans intérêt.
-
Je suis d'accord avec vous @Zoc mais je ne peux pas expliquer pourquoi la modification de l'option 11 m'a permis de restaurer ipv6 sans autre changement.
-
Je suis d'accord avec vous @Zoc mais je ne peux pas expliquer pourquoi la modification de l'option 11 m'a permis de restaurer ipv6 sans autre changement.
Est ce que l'on peut résumer en disant que le branchement de la BOX a débloqué l'attribution d'une IPv6 ?
-
Pas sûr qu'on puisse dire ça. Si tel était le cas, je n'aurais pas dû changer l'option 11
-
Pas sûr qu'on puisse dire ça. Si tel était le cas, je n'aurais pas dû changer l'option 11
Beaucoup de modifications en 1 seule fois, donc vous ne savez pas quelle action unique a débloqué l'attribution d'une IPv6...
Je dis ça pour voir si mon cas (juste avant) était récurant chez d'autres personnes et pouvait aider a comprendre le mécanisme que Orange a mis en place
-
Oui, mais j'ai réessayé avec mon routeur après avoir connecté la livebox. Cela ne fonctionnait que si je changeais l'option 11. Donc, la livebox ne "déverrouille" pas ipv6
-
@jeremyp3
Bonsoir,
j'ai remplacé le câble d'orange entre l'ONT et l'Erl3 par un câble Cat7 S/FTP, malheureusement aucun changement, le débit iperf3 reste 100/100...
/run/dhclient_eth1_832.leases, comporte: option dhcp-message-type 5; est-ce une nouvelle option?
Konki
-
Non. C'est juste le type de la réponse du serveur DHCP.
-
Bonjour,
Est-ce que la LiveBox utilise toujours le même "salt" entre sa requête DHCPv4 et la requête DHCPv6 ?
Ou est-ce que les deux clients DHCP génèrent leurs chaînes random indépendamment ?
-
Les 2 clients génèrent leur salt indépendamment.
-
Ah oui. OPNsense 18.7.9 a introduit le support DUID complet pour les types DUID tels que LL LLT UUID. Mais on dirait que vous devez définir le DUID maintenant ou aucun n'est créé. Je vais partager avec les développeurs. J'avais oublié que j'avais changé ça aussi.
REMARQUE: j'ai capturé le DUID à partir de la livebox. Option d'identification du client de la demande DHCP6c afin que je corresponde exactement à la livebox. Cela peut être vérifié dans le futur. DUID est au format LL et est 00: 03: 00: 01: AddressMacEth1.
Interfaces > Settings > DHCP Unique Identifier
-
Pour ceux qui sont sur Marseille:
option domain-search "MAR.access.orange-multimedia.net.";
-
Salut tout le monde
je suis sur Metz et j'ai un Edge PO5. Comme certains je n'ai plus le Tel.
j'ai commencé à lire ce thread mais j'avoue que je ne comprends pas trop ce qu'il faut faire.
est ce que quelqu'un pourrait faire une synthèse de ce que nous devrions faire pour que cela fonctionne ?
merci encore pour vos recherches.
PS : au rythme où cela change je me demande s'il ne faut pas changer de provider (je songe à BT)
-
merci encore pour vos recherches.
PS : au rythme où cela change je me demande s'il ne faut pas changer de provider (je songe à BT)
C'est la raison de ma migration vers OVH.
Tous les services tierces d'Orange ne intéressement pas, je veux uniquement un lien fiable et performant vers Internet.
-
C'est la raison de ma migration vers OVH.
Tous les services tierces d'Orange ne intéressement pas, je veux uniquement un lien fiable et performant vers Internet.
👍 👌
-
Salut tout le monde
je suis sur Metz et j'ai un Edge PO5. Comme certains je n'ai plus le Tel.
j'ai commencé à lire ce thread mais j'avoue que je ne comprends pas trop ce qu'il faut faire.
est ce que quelqu'un pourrait faire une synthèse de ce que nous devrions faire pour que cela fonctionne ?
merci encore pour vos recherches.
PS : au rythme où cela change je me demande s'il ne faut pas changer de provider (je songe à BT)
+1
Il serait intéressant d'établir un récap' purement technique de la configuration qu'utilise Orange.
-
Hello :),
Ma téléphonie ne fonctionnant plus, j'ai essayé de recouper un peu les dernières infos d'ici, si cela peut en aider d'autres.
Je suis sous un Mikrotik RB3011UiAS-RM, j'avais ceci, jusqu'à ce que la téléphonie ne fonctionne plus depuis une ou deux semaines :
0x00067362637433670341554206616363657373116f72616e67652d6d756c74696d65646961036e657400
sbct3g.AUB.access.orange-multimedia.net
Je suis de Rouen, Normandie, donc j'ai logiquement essayé en option 90 sbct3g.ROU.access.orange-multimedia.net
Au premier coup cela ne fonctionnait pas (offre Livebox v3 Sosh)
J'ai rajouté l'option 125 vendor_specific 0x000005580c010a0000000000ffffffffff dans les options DHCP, et poof, ça a refonctionné.
Juste par curiosité, j'ai regardé si le nom de domaine répondait, du moins qu'il avait une IP d'attribué.
Par un CMD cela ne fonctionne pas, mais en direct sur la Livebox ou via Winbox on voit bien si le nom de domaine est valable.
La requête Ping n’a pas pu trouver l’hôte PUT.access.orange-multimedia.net. Vérifiez le nom et essayez à nouveau.
Envoi d’une requête 'ping' sur sbct3g.ROU.access.orange-multimedia.net [81.253.173.236] avec 32 octets de données :
Envoi d’une requête 'ping' sur sbct3g.PUT.access.orange-multimedia.net [81.253.173.236] avec 32 octets de données :
Envoi d’une requête 'ping' sur sbct3g.NIC.access.orange-multimedia.net [81.253.173.233] avec 32 octets de données :
La requête Ping n’a pas pu trouver l’hôte NIC.access.orange-multimedia.net. Vérifiez le nom et essayez à nouveau.
Envoi d’une requête 'ping' sur sbct3g.AUB.access.orange-multimedia.net [81.253.173.247] avec 32 octets de données :
La requête Ping n’a pas pu trouver l’hôte sbct3g.LIS.access.orange-multimedia.net. Vérifiez le nom et essayez à nouveau.
Envoi d’une requête 'ping' sur sbct3g.CAE.access.orange-multimedia.net [81.253.173.235] avec 32 octets de données :
La requête Ping n’a pas pu trouver l’hôte sbct3g.PAR.access.orange-multimedia.net. Vérifiez le nom et essayez à nouveau.
Envoi d’une requête 'ping' sur sbct3g.LIL.access.orange-multimedia.net [81.253.173.237] avec 32 octets de données :
J'en déduis donc que les serveurs Orange disponibles pour la téléphonie ne seraient donc que les "grandes villes" de région, comme Lisieux de basse Normandie ne fonctionne pas, mais Rouen et Caen fonctionnent :).
(Rouen et Puteaux ont la même IP apparemment aussi, à vérifier si cela fonctionne)
LIL = Lille je suppose.
-
J'ai rajouté l'option 125 vendor_specific 0x000005580c010a0000000000ffffffffff dans les options DHCP, et poof, ça a refonctionné.
Hello, au passage pour ma part, j'ai ça dans ma conf DHCP :
00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
J'ai entendu parler (il y a un moment) que cette variation avait une importance. Toujours d'actualité?
Pour le moment tout marche avec les options 90 120 et 125 donc je touche à rien ;D
-
je viens vous donner un retour
j'ai regardé dans mon fichier /run/dhclient_eth1_832.leases
donc j'ai modifié le domain-search en conséquence (en l'occurence NCY)
...
option domain-search "NCY.access.orange-multimedia.net.";
=> KO
ensuite j'ai modifié l'option 125 avec l'info fourni par Skykill
=> KO
Une idée de ce qui ne va pas ?
merci
-
je viens vous donner un retour
j'ai regardé dans mon fichier /run/dhclient_eth1_832.leases
donc j'ai modifié le domain-search en conséquence (en l'occurence NCY)
...
option domain-search "NCY.access.orange-multimedia.net.";
=> KO
ensuite j'ai modifié l'option 125 avec l'info fourni par Skykill
=> KO
Une idée de ce qui ne va pas ?
merci
As-tu essayé avec sbct3g devant ? Car sans, les adresses n'avaient pas d'IP pour moi :).
-
C'est un "domain search", normal que ça ne résolve pas...
La box essaye de résoudre "sbct3g", ce qui en pratique, grâce au domain search, se transforme en "sbct3g.NCY.access.orange-multimedia.net.".
-
je viens vous donner un retour
j'ai regardé dans mon fichier /run/dhclient_eth1_832.leases
donc j'ai modifié le domain-search en conséquence (en l'occurence NCY)
tu as bien les " dans la config (ils sont nécessaires pour que l'interpréteur génère les guillements). Ca devrait donner ça:
shared-network-name VLAN_LIVEBOX_DHCP {
authoritative enable
subnet 192.168.10.0/24 {
default-router 192.168.10.1
dns-server 80.10.246.3
dns-server 81.253.149.10
lease 172800
start 192.168.10.30 {
stop 192.168.10.50
}
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;"
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
subnet-parameters "option domain-search "NCY.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
}
}
Il est possible que les DNS à utiliser soient différents des miens. Là aussi voir dans le fichier /run/dhclient_eth1_832.leases
-
hello
voici ce que j'ai dans mon config.boot
shared-network-name LIVEBOX {
authoritative enable
subnet 192.168.1.0/24 {
default-router 192.168.1.1
dns-server 81.253.149.9
dns-server 80.10.246.1
domain-name orange.fr
lease 86400
start 192.168.1.2 {
stop 192.168.1.254
}
subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78
subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:41:55:42:06:61:63:63:65:73:73:11:6f:72:61:6e:67
subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
subnet-parameters "option domain-search "sbct3g.NCY.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
}
et ce que j'ai dans le fichier /runt/dhclient_eth1_832.leases
root@ubnt:/config# more /run/dhclient_eth1_832.leases
lease {
interface "eth1.832";
fixed-address xxxxxxxxxxxxxxxxxxxxxx;
option subnet-mask 255.255.248.0;
option routers 83.196.8.1;
option dhcp-lease-time 259200;
option dhcp-message-type 5;
option domain-name-servers 81.253.149.13,80.10.246.5;
option dhcp-server-identifier 80.10.247.48;
option domain-search "NCY.access.orange-multimedia.net.";
option unknown-120 0:6:73:62:63:74:33:67:3:4e:43:59:6:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:6
4:69:61:3:6e:65:74:0;
option dhcp-renewal-time 82631;
option rfc3118-auth 0:0:0:0:0:0:0:0:0:0:0:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30;
option broadcast-address 83.196.15.255;
option dhcp-rebinding-time 207400;
option domain-name "orange.fr";
option vendor.unknown-1368 1:a:0:1:0:0:0:ff:ff:ff:ff:ff;
renew 1 2018/12/31 17:01:44;
rebind 3 2019/01/02 07:06:45;
expire 3 2019/01/02 21:30:05;
}
comment savoir si le DNS est correct ?
-
voici ce que j'ai dans mon config.boot
subnet-parameters "option domain-search "sbct3g.NCY.access.orange-multimedia.net.";"
Il ne faut absolument pas qu'il y ait "sbct3g." dans le domain-search !
Accessoirement, il faut enlever le "domain-name orange.fr" car il est maintenant configuré par un "subnet-parameters". la commande "domain-name" d'EdgeOS à tendance à écraser à la fois les options domain-name et domain-search...
et ce que j'ai dans le fichier /runt/dhclient_eth1_832.leases
root@ubnt:/config# more /run/dhclient_eth1_832.leases
lease {
option domain-name-servers 81.253.149.13,80.10.246.5;
}
comment savoir si le DNS est correct ?
Les DNS à utiliser sont ceux là, et pas 81.253.149.9 ni 80.10.246.1.
-
En fait j'avais ajouté le sbt3c pour test mais je suis revenu à la config que tu avais spéficié.
Pour ce qui est du domain search je ne chage rien pour le moment.
du coup à quoi serait du mon souci ?
-
Si la téléphonie ne fonctionne toujours pas alors je ne sais pas, ça fonctionne avec ces paramètres chez tous ceux qui utilisent la LB derrière leur routeur pour le téléphone...
Est-ce que la téléphonie fonctionne Livebox branchée directement à l'ONT ?
-
j'ai pas encore testé le branchement en direct
par contre un truc zarb
dans le post précèdent je vous avais envoyé le contenu du fichier leases
root@ubnt:/config# more /run/dhclient_eth1_832.leases
lease {
option domain-name-servers 81.253.149.13,80.10.246.5;
}
par contre en regardant dans mon fichier de conf voici ce que j'ai
shared-network-name LIVEBOX {
authoritative enable
subnet 192.168.1.0/24 {
default-router 192.168.1.1
dns-server 81.253.149.9
dns-server 80.10.246.1
domain-name orange.fr
comment est ce possible sachant que j'ai rebooté mon routeur plusieurs fois ?
Sinon vous confirmer que les dns-server sont bien ceux du fichier de leases ? dans ce cas j'adapter mon fichier config.boot
merci encore
-
Sinon vous confirmer que les dns-server sont bien ceux du fichier de leases ?
ben oui, le fichier leases contient la réponse du dhcp d'orange ... donc les dns entre autre.
si vous n'avez pas les bon dans votre configuration, c'est normal que ça ne fonctionne pas ...
-
J'ai pris les DNS attribués en direct par la Livebox me concernant.
80.10.246.1
81.253.149.9
J'avais ceux-ci avant que ça ne fonctionne plus (je les ai juste mis à jour en passant, mais je ne pense pas que ça aurait bloqué).
80.10.246.3
81.253.149.10
-
je viens donner mon retour
effectivement le DNS-SERVER a du être adapté dans mon fichier de config comme l'a indiqué jemeryp3 et hop mon telephone a fonctionné
après reboot de mon routeur et de ma box.
En espérant que cette config ne va pas encore changer dans quelques jours.
Merci encore
-
Alors là j'avoue que je ne comprends plus rien.
je m'explique ayant un ping vraiment moins qu'auparavant (9ms désormais alors qu'avant j'étais à mois de 5 ms) je me suis dis
je vais retenter de rebasculer mes valeurs dns sur mon edge router1
et là :
- ping toujours identique : environ 9ms pour www.google.fr
- mais ce qui me dérange c'est que le téléphone fonctionne aussi (alors que je pensais que cela ne fonctionnerait plus)
la seule chose que j'ai oublié de mentionné dans le post d'avant c'est que j'ai retiré le" domain-name orange.fr"
une idée du souci ?
merci
-
je vais retenter de rebasculer mes valeurs dns sur mon edge router1
- mais ce qui me dérange c'est que le téléphone fonctionne aussi (alors que je pensais que cela ne fonctionnerait plus)
ça marche encore parce que le changement est tout récent et que la liveboite a encore l'ip dans son cache. mais un changement de dns ne réduit pas le ping ça peut changer le serveur sur lequel tu te connectes, mais rien de plus ... ;)
Jerem
-
une idée du souci ?
ça peut aussi bien venir d'un changement d'infrastructure chez google, pour peu que d'un coup, tu attaques un serveur google situé un peu plus loin.
pour bien faire il faudrait comparer un traceroute avant et après, ce que tu n'as pas enregistré j'imagine...
-
Bonjour a tous,
Comme le tel ne marche plus chez moi, j'ai essayé de faire la modification du config.boot en vi via ssh.
J'ajoute les 2 lignes suivantes :
subnet-parameters "option domain-search "AUB.access.orange-multimedia.net.";"
subnet-parameters "option domain-name "orange.fr";"
puis save, puis reboot
Malheureusement, le router ne prend pas en compte la configuration, la bonne nouvelle est qu'il repart avec la config par default en 192.168.1.1 et je peux lui reinjecter la configuration d'orgine.
Vous procedez comment pour les changement de config, je le fais si rarement que j'ai probablement oublier le bon process.
Merci par avance,
Jean.
-
Hello, plus de téléphone depuis ce soir (sans doute depuis quelques jours, je viens de m'en rendre compte)...
Es-ce que ça aurait un lien avec l'authentification "longue" de l'option 90?
J'utilise la version courte
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
D'ailleurs, faudrait que je lance une capture des trames pour voir ce qui est échangé avec la LB
-
La téléphonie utilise sa propre méthode d'authentification dont ça m'étonnerait que l'option 90 ait un impact.
Par contre courant décembre Orange a changé l'option utilisée pour transmettre l'adresse du serveur SIP à la box. Exit l'option 120, maintenant c'est une autre et tout est décrit dans les pages précédentes de ce fil ;)
-
Est-ce qu'il y a un résumé des changements quelque part SVP? Est-ce que le client dhcp à changé?
---
J'ai changé l'option 90 en insérant 1a:09:00:00:05:58:01:03:41:01:0d.
J'ai mis ces serveurs DNS:
81.253.149.13
80.10.246.5
Et le reste des options:
option SIP 00:06:73:62:63:74:33:67:03:41:55:42:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;
option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;
option domain-search "NCY.access.orange-multimedia.net.";
option domain-name "orange.fr";
J'ai tout redémarré, toujours pas de téléphone
-
Ca commence ici:
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg596234/#msg596234
Option 119 à rajouter. Contenu dépendant de la localisation de la box.
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg596704/#msg596704
(Attention, tu es certain que "NCY" existe ?)
-
OK merci
Est-ce que un redémarrage du routeur est nécessaire ou un release/renew suffit? Et redémarrage box évidemment
-
Uniquement redémarrage de la box.
-
Uniquement redémarrage de la box.
ça fonctionne toujours pas (la box n'a plus accès à internet) c'est vraiment tout ce qui à changé?
-
Oui.
-
J'ai peux être un dhclient patché trop vieux? La dernière fois que je l'ai téléchargé ça doit faire plus de 3 mois
-
la box n'a plus accès à internet
Alors c'est plus grave qu'un simple problème de téléphonie.
-
J'ai peux être un dhclient patché trop vieux
dhclient est utilisé coté WAN. Rien à voir donc...
J'utilise le même dhclient depuis 2 ans.
-
Voici un diff entre les deux 'config.boot', celui avec lequel la box avait accès à internet mais plus de tél, et l'autre où la box a plus rien du tout:
438,439c438,440
< dns-server 81.253.149.13
< dns-server 80.10.246.5
---
> dns-server 81.253.149.9
> dns-server 80.10.246.1
> domain-name orange.fr
448,452c449,451
< subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;"
< subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:4e:49:43:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
< subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff;"
< subnet-parameters "option domain-search "TOU.access.orange-multimedia.net.";"
< subnet-parameters "option domain-name "orange.fr";"
---
> subnet-parameters "option rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;"
> subnet-parameters "option SIP 00:06:73:62:63:74:33:67:03:41:55:42:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00;"
> subnet-parameters "option Vendor-specific 00:00:05:58:0c:01:0a:00:00:00:00:00:ff:ff:ff:ff:ff;"
J'ai mis TOU pour Toulouse mais c'est peut être pas ça...
-
L'option 90 (rfc3118-auth) n'a aucune raison de changer entre les 2 versions. La modification de l'option ne concerne que ce que l'ERL doit envoyer à Orange. Pas la réponse que le routeur doit envoyer à la box. Ca explique pourquoi elle ne se connecte même plus à Internet.
Le plus simple pour savoir quoi mettre dans le domain-search, c'est de regarder ce qu'Orange envoie... (visible dans le fichier /run/dhclient_eth1_832.leases sur le routeur).
-
J'ai compris, j'avais tout mélangé.
Justement j'ai regardé ce fichier et remplacer par ce que mon routeur reçois de Orange et ça marche.
Merci
-
Bon avec mon matériel je ne peux pas récupérer la réponse DHCP d'Orange...
Voici ce qu'envoie ma LB pour se connecter :)
On notera l'option 61 qui contient l'adresse MAC de la box (aucune idée si c'est propre au mécanisme "standard" de DHCP ou si c'est une conf spécifique d'Orange)
-
On notera l'option 61 qui contient l'adresse MAC de la box (aucune idée si c'est propre au mécanisme "standard" de DHCP ou si c'est une conf spécifique d'Orange)
Oui, d'ailleurs je l'envoie aussi même s'il semble que ça marche sans.
client-option "send dhcp-client-identifier 1:24:7f:20:xx:xx:xx;"
-
Hello, plus de téléphone depuis ce soir (sans doute depuis quelques jours, je viens de m'en rendre compte)...
Es-ce que ça aurait un lien avec l'authentification "longue" de l'option 90?
J'utilise la version courte
D'ailleurs, faudrait que je lance une capture des trames pour voir ce qui est échangé avec la LB
Ca commence ici:
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg596234/#msg596234
Option 119 à rajouter. Contenu dépendant de la localisation de la box.
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg596704/#msg596704
(Attention, tu es certain que "NCY" existe ?)
C'était ça! la téléphonie refonctionne :)
Au final j'utilise ça :
DHCP
- 81.253.149.10
- 80.10.246.3
Dans l'interface de OPNsense
- domain name : orange.fr
- demain search list (option 119) : AUB.access.orange-multimedia.net
- lease time 86400
et en manuel
option 90 : 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30 (dhcpliveboxfr250)
option 120 : 00:06:73:62:63:74:33:67:03:41:55:42:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00 (AUB)
option 125 : 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
Tout est fonctionnel.
Oui, d'ailleurs je l'envoie aussi même s'il semble que ça marche sans.
client-option "send dhcp-client-identifier 1:24:7f:20:xx:xx:xx;"
Merci, je vais me pencher là-dessus
-
Oui, d'ailleurs je l'envoie aussi même s'il semble que ça marche sans.
client-option "send dhcp-client-identifier 1:24:7f:20:xx:xx:xx;"
Une petite question, en hexa, wireshark présente l'option 61 commençant par : 3d:07:01:mac, tu oublie volontairement les 2 premiers octets dans ta configuration?
-
3D = 61 = numéro de l'option ;)
07 = longueur ('01' + 6 octets de la mac).
Ces octets sont évidements ajoutés automatiquement par le client DHCP.
-
Au final j'utilise ça :
DHCP
- 81.253.149.10
- 80.10.246.3
Dans l'interface de OPNsense
- domain name : orange.fr
- demain search list (option 119) : AUB.access.orange-multimedia.net
- lease time 86400
et en manuel
option 90 : 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30 (dhcpliveboxfr250)
option 120 : 00:06:73:62:63:74:33:67:03:41:55:42:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00 (AUB)
option 125 : 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
Ayant pas mal de problème avec l'ajout de l'option 119, j'ai fait une série de tests pour comprendre le problème.
Et j'ai pu constate que l'on peut se passer cette option domain-search-list à condition de ne pas mettre d'option domain-name.
Sans les 2, tout rentre dans l'ordre, je pense que dans ce cas, c'est l'option sip (120) qui prime. C'est finalement plus simple.
Pour revenir au problème de l'option domain-search-list, la chaine est envoyée correctement mais tronquée lors de son utilisation. En effet, en analysant le trafic de la box, j'ai vu une requête DNS sur sbct3g.XX.access.orange-multimedia.net juste avant la première requête SIP (un register). Cette résolution échoue puisqu'il aurait fallu la faire sur XXX. Et ensuite la séquence SIP n'obtient pas de réponse. Si on supprime l'option domain-name, il n'y a pas de résolution DNS et le register SIP se fait directement sur la bonne destination (obtenue sûrement par l'option sip)! Workaround si on veut garder l'option domain-name, dans mon cas, mettre un caractère de plus, à savoir ".XXX.access.orange-multimedia.net." comme domain-search-list.
En conclusion, il est possible de partir juste sur
option 90 : 00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30 (dhcpliveboxfr250)
option 120 : 00:06:73:62:63:74:33:67:03:xx:xx:xx:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00 (XXX)
option 125 : 00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff
Avec les bons DNS bien sûr.
Configuration validée sur mon Ubiquiti USG.
-
L’option SIP va disparaître bientôt...
-
Surement...mais pas très logique puisque justement l'option 120 a été crée pour fournir, via dhcp, l'adresse du serveur SIP aux clients.
Cela me semble beaucoup plus "standard" que la dernière évolution avec l'option 119...un peu étonnant comme choix technique de la part d'Orange.
-
Perso dans le bail DHCP d'Orange, j'ai les 2 options, je renvoie les 2 à la LB...
-
Salut
Je viens d'etre connecte en fibre livebox 4 sosh
J'ai un serveur ubuntu 16.04
pas moyen d'avoir une ip sur
eth0.832 Link encap:Ethernet HWaddr 68:05:ca:19:aa:2e
inet6 addr: fe80::6a05:caff:fe19:aa2e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:16055 (16.0 KB)
un probleme d'authentification à mon avis
j'ai pas tout lues les 42 posts mais a mon avis il me manque des choses dans mon dhclient.conf
option rfc3118-authentication code 90 = string;
interface "eth0.832" {
send vendor-class-identifier "sagem";
#send dhcp-client-identifier xx:xx:xx:xx:xx:xx;#maclivebox
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox4";
send rfc3118-authentication 00:00:00:00:00:00:00:00:00:00:00:66:74:69:xx:xx:xx:xx:xx:xx:xx:xx;
request subnet-mask, routers,
domain-name, broadcast-address, dhcp-lease-time,
dhcp-renewal-time, dhcp-rebinding-time,
rfc3118-authentication;
prepend domain-name-servers 8.8.8.8, 8.8.4.4;
}
les xx.xx.xx j'ai bien mis le fti/...... en hexa
dois je mettre
send rfc3118-authentication 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:66:74:69:xx:xx:xx:xx:xx:xx:xx:xx;
Merci de l'aide
-
Es-tu par hasard en zone qui nécessite de mettre une priorité à 6 pour le DHCP ?
-
Es-tu par hasard en zone qui nécessite de mettre une priorité à 6 pour le DHCP ?
Merci oui
apres avoir tout suivi j'ai reussi à avoir une ip
-
J’ai pas de limite de débit avec les options qui avaient été données au début du sujet. Par contre, depuis quelques temps, je suis limité à 10 Mbps en up sur le ssh. J’ai pas tenté de le faire passer par un autre port pour voir, mais en tout cas en NFS vers le même serveur je monte au max.
Exactement le même souci, débit très limité en SSH up/down, environ 10 Mbps.
Même en utilisant un autre port que le 22.
Aucun souci à priori sinon, je plafonne la ligne avec un Speedtest.
J'ai tenté en réutilisant la Livebox, je plafonne bien la ligne via SSH...
Une idée ?
Merci !
-
Je pense que c’est un effet de bord de la gestion de la CoS sur nos routeurs. Les paquets SSH doivent avoir un DSCP qui est transformé en CoS 6 par le routeur (dans le kernel il y a une table statique qui mappe IP_TOS vers une priorité interne)... La Livebox doit s’y prendre autrement.
-
J'ai pourtant tenté en remettant toutes les CoS egress_map à 0, c'est pareil :-\
Ca voudrait dire que le kernel modifie de nouveau cela après la config faite par vconfig...
Ca commence à être un peu touchy ;D
-
Non, si le problème persiste après avoir remis à 0 l’egress Map alors ce n’est pas ça le problème. Autant le kernel se base sur sa table IP_TOS pour configurer la priorité interne, autant il n’utilise rien d’autre que l’egress Map pour déterminer la CoS 802.1p à partie de la prio interne.
-
Si j'utilise l'option SSH -o IPQoS=0x00 alors je retrouve déjà des débits plus normaux...
Effectivement, par défaut, SSH utilise un TOS 0x20 pour les paquets de data.
Il y a donc bien une affectation réalisée quelque part en fonction du champ TOS...
IPQoS
Specifies the IPv4 type-of-service or DSCP class for the connection. Accepted values are af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43,cs0, cs1, cs2, cs3, cs4, cs5, cs6, cs7, ef, lowdelay, throughput, reliability, or a numeric value. This option may take one or two arguments, separated by whitespace. If one argument is specified, it is used as the packet class unconditionally. If two values are specified, the first is automatically selected for interactive sessions and the second for non-interactive sessions. The default is lowdelay for interactive sessions and throughput for non-interactive sessions.
-
Si on se base là dessus : https://www.tucny.com/home/dscp-tos
Et sur la règle suivante : iptables -t mangle -A POSTROUTING -j DSCP --set-dscp XX
Sur un Netgear R7000, voici les valeurs DSCP que j'ai testées, et ce qu'elles donnent :
KO : 0 (étrange car les paquets issus d'un Speedtest par exemple et traversant le routeur on bien un champ TOS à 0) (cf 2 posts plus bas)
OK : 1, 2, 3, 4, 5, 6, 7
KO : 8, 10, 12, 14, 16
OK : 9, 11, 13, 15, 17
Quand c'est OK, je retrouve les débits de la Livebox, je plafonne la ligne.
Bon je tatonne...
L'idéal serait de ré-analyser le trafic entre la Livebox et l'ONT pour faire un récap des champs TOS et éventuellement des CoS.
Quelqu'un saurait le faire ? Je n'ai pas le matos pour dans l'immédiat :-\
Ou alors une autre idée ?
Merci !
-
L'idéal serait de ré-analyser le trafic entre la Livebox et l'ONT pour faire un récap des champs TOS et éventuellement des CoS.
Quelqu'un saurait le faire ? Je n'ai pas le matos pour dans l'immédiat :-\
Ou alors une autre idée ?
Merci !
Tout ce qui suit est basé sur une pcap de livebox à Puteaux dans le 92 qui date du 15/10/2018, en filtrant "vlan.priority != 0":
- ARP: vlan.priority = 7i|6e (pas IP, pas de DSCP)
- ICMPv6 (important pour NDP!): vlan.priority = 7i|6e, DSCP "CS6" 0xc0
- DHCP: vlan.priority = 7i|6e, DSCP = "CS6" 0xc0
Quand j'écris 7i/6e c'est:
- 7 ingress: prio des paquets ethernet vlan 802.1q reçus des équipements orange
- 6 egress: prio des paquets ethernet vlan 802.1q envoyés par la livebox
Remarque: il y a aussi des prio non nulles <= 7 assignées sur des paquets IGMP, DNS, SIP, etc
Avec linux debian, pour envoyer les paquets vlan 802.1q avec la bonne vlan.prio (et la bonne DHCP si IP):
1. egress map assigné avant que les "handshake ethernet/IP" n'aient lieu, quand le router linux reboot:
On ne map que la valeur 6 qui nous intéresse pour envoyer des paquets ARP, ICMPv6, DHCP
auto enp1s0.832
iface enp1s0.832 inet dhcp
pre-up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
iface enp1s0.832 inet6 dhcp
pre-up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
request_prefix 1
accept_ra 2
2. ARP / ICMPv6:
Désolé c'est du "nftables", mais c'est pareil avec iptables:
table arp arp4 {
chain output {
type filter hook output priority 0; policy accept;
oifname $if_wan meta priority set 6 counter
}
}
table ip6 fltr6 {
chain assign-orange-prio {
icmpv6 type { nd-neighbor-solicit, nd-router-solicit} ip6 dscp set cs6 meta priority set 0:6 counter packets 4 bytes 264
udp sport dhcpv6-client ip6 dscp set cs6 meta priority set 0:6 counter packets 11 bytes 3353
}
}
On change à la fois la valeur DSCP voulue (pour les paquets IP), et la meta priority voulue. La meta priority sera ensuite convertie correctement en priorité vlan 802.1q par la egress map définie au point 1. ci-dessus.
3. DHCP
est géré par des programmes genre ISC-DHCP client/server, ou autres, qui sont TOUS obligés d'utiliser des sockets "SO_PACKET" (appelés RAW par certains) pour forger des paquets IP/DHCP corrects.
Ces sockets "SO_PACKET" sont hookées en egress de telle sorte que netfilter ne puisse pas agir dessus (ni les filtrer, ni modifier les paquets).
Pour ceux qui utilisent ISC DHCP client, ce dernier NE PERMET PAS de configurer une meta priorité (skbuff priority).
Il faut donc modifier son code source pour envouyer les bons meta priorité et DSCP...
Ensuite, le map egress 802.1q fait le reste.
-
Merci pour ton retour Strangelovian.
Pour résumer, car j'ai fini par trouver le fin mot de l'histoire :)
La plupart du traffic qui traverse le routeur a un champ TOS à 0x00, c'est le cas par exemple d'un Speedtest.
SSH, par exemple, pour sa part, fixe le champ TOS pour un transfert de fichier à 0x20, les débits sont alors catastrophiques.
Si on utilise l'option SSH -o IPQoS=0x00 pour fixer le TOS à 0x00, on retrouve des débits normaux.
A mon sens cela veut donc dire que des équipements Orange surveillent / s'adaptent selon le champ TOS...
OK, forçons donc le TOS à 0x00 pour tous les paquets traversant le routeur :
iptables -t mangle -D POSTROUTING -j TOS --set-tos 0x00
Et bien sur DD-WRT cela ne fonctionnait pas...
Le "bug" vient d'être corrigé (https://svn.dd-wrt.com/changeset/39106), et était lié au Shortcut Forwarding Engine qui ne forçait pas un TOS spécifiquement positionné à 0x00...
Et ça m'a pas mal induit en erreur...
Donc maintenant c'est cohérent :)
Sur Mikrotik aucun souci (attention cependant il faut désactiver le fasttrack, je n'ai pas trouvé comment faire autrement pour le moment).
Voilà donc, il peut sembler judicieux de fixer le champ TOS, étant donné que l'on ne maitrise pas ce que les applications font elles-mêmes...
-
Sur Mikrotik aucun souci (attention cependant il faut désactiver le fasttrack, je n'ai pas trouvé comment faire autrement pour le moment).
Mangle peut être utilisé pour sélectionner et marquer les connexions à ne pas 'fastracker'.
-
Mangle peut être utilisé pour sélectionner et marquer les connexions à ne pas 'fastracker'.
Alors prenons l'exemple justement d'une connexion SSH.
Lors de l'établissement de la connexion, SSH envoie ses paquets avec un TOS à 0x00.
Une fois la connexion établie, pour les paquets de data, SSH positionne le TOS à 0x20.
Pas possible donc de faire le matching des connexions à ne pas fastracker sur un TOS != 0x00
(car le premier paquet a un TOS 0x00, la connexion est donc déjà fastrackée).
Une idée ? :)
-
Je pensais plutôt à identifier l'intégralité du flux pour certains types de connexion, ici SSH vers l'extérieur. Il doit être possible de le faire de cette façon (pas testé) en complèment du changement de TOS :
# Marquer les connexions SSH venant du LAN vers le net
/ip firewall mangle
add chain=prerouting action=mark-connection \
connection-mark=no-mark \
in-interface=<côté_LAN> protocol=tcp dst-port=22 out-interface=<côté_WAN>\
new-connection-mark=no_fasttrack
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related \
connection-mark=no-mark
-
Tu ne peux pas matcher la output-interface en prerouting (logique).
Pourquoi ne pas dire que tu TOS à 0x00 tous les paquets, sauf les paquets specifiques necessaires à Orange (c'est la requête DHCP il me semble ?)
Si tu commences à mangle dans tous les sens, tu vas te prendre le choux ... Ca va devenir un setup hyper complexe, pour juste pas grand chose au final (oui je sais , Orange fait chier).
Aussi, gros conseil : désactive le fasttrack. Ca marche pas avec le mangle, et avec plein d'autres choses (comme le marquage de paquets et les queues par exemple,puisque ca bypass tout le Kernel).
Si tu as besoin de commencer à jouer avec Mangle, il faut virer fasttrack. Ca m'a pris la tête à moi, et à bcp d'autres personnes plutot calées en Mikrotik (ping @Hugues ?), le fasttrack, c'est bien si tu mangle pas, sinon ca va te jouer plein de tours invisibles et hyper relous à débogguer.
-
Pour info sinon je suis arrivé à ceci, un peu plus générique que de fonctionner par ports, et qui fonctionne :
/ip firewall mangle
add action=mark-connection chain=postrouting connection-bytes=1-10000 connection-mark=no-mark dscp=!0 new-connection-mark=nofasttrack out-interface=vlan832 passthrough=yes
add action=change-dscp chain=postrouting dscp=!0 new-dscp=0 out-interface=vlan832 passthrough=yes
/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-bytes=10001-0 connection-mark=no-mark connection-state=established,related
Le principe est d'analyser les 10 premiers Ko de la connexion, si on trouve un TOS != 0 alors la connexion n'est pas fasttrackée, sinon elle l'est.
On fait donc le pari que si l'on n'a pas vu un TOS != 0 dans les premiers X Ko, on n'en verra pas ensuite...
Le défaut c'est que les connexions en dessous du seuil des X Ko ne sont pas fasttrackées. Bon...
-
Pour info sinon je suis arrivé à ceci, un peu plus générique que de fonctionner par ports, et qui fonctionne :
/ip firewall mangle
add action=mark-connection chain=postrouting connection-bytes=1-10000 connection-mark=no-mark dscp=!0 new-connection-mark=nofasttrack out-interface=vlan832 passthrough=yes
add action=change-dscp chain=postrouting dscp=!0 new-dscp=0 out-interface=vlan832 passthrough=yes
/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-bytes=10001-0 connection-mark=no-mark connection-state=established,related
Le principe est d'analyser les 10 premiers Ko de la connexion, si on trouve un TOS != 0 alors la connexion n'est pas fasttrackée, sinon elle l'est.
On fait donc le pari que si l'on n'a pas vu un TOS != 0 dans les premiers X Ko, on n'en verra pas ensuite...
Le défaut c'est que les connexions en dessous du seuil des X Ko ne sont pas fasttrackées. Bon...
Bien vu, et c'est pas pour 10 Ko que le routeur va s'écrouler :)
Il ne me semble pas avoir vu d'autres personnes signaler un problème lié à TOS, en dehors de SSH ?
@doctorrock : je te rejoins sur fasttrack. Premier réflexe en cas de pépin, le virer pour voir ...
-
Bonjour :)
Fraichement abonné Sosh Fibre, et équipé d'un routeur TP-Link Acer C7, je vais bientôt rejoindre votre clan des remplaceurs de Livebox ;D
J'ai déjà le convertisseur de média TP-Link MC220L, ya plus qu'à !
Si on se base là dessus : https://www.tucny.com/home/dscp-tos
Et sur la règle suivante : iptables -t mangle -A POSTROUTING -j DSCP --set-dscp XX
Sur un Netgear R7000, voici les valeurs DSCP que j'ai testées, et ce qu'elles donnent :
KO : 0 (étrange car les paquets issus d'un Speedtest par exemple et traversant le routeur on bien un champ TOS à 0) (cf 2 posts plus bas)
OK : 1, 2, 3, 4, 5, 6, 7
KO : 8, 10, 12, 14, 16
OK : 9, 11, 13, 15, 17
Quand c'est OK, je retrouve les débits de la Livebox, je plafonne la ligne.
Bon je tatonne...
L'idéal serait de ré-analyser le trafic entre la Livebox et l'ONT pour faire un récap des champs TOS et éventuellement des CoS.
Quelqu'un saurait le faire ? Je n'ai pas le matos pour dans l'immédiat :-\
Ou alors une autre idée ?
Merci !
Si ça vous intéresse, j'ai intercalé un switch manageable entre la Livebox V4 et le convertisseur MC220L.
Je suis donc en mesure de faire toutes les captures que vous souhaitez 8)
Je vais tenter une capture d'un transfert TFTP.
-
Je viens donc de réaliser le test ci-dessous :
- Serveur SSH (OpenSSH) présent sur mon LAN (derrière double NAT OpenWRT + Livebox)
- Transfert TFTP depuis un client (FileZilla) situé sur Internet
- 3 captures Wireshark réalisées : côté serveur, côté client, et entre la Livebox et le SFP.
Résultat :
- côté client
flag DCSP des entêtes IP reçues = 0x00
flag DCSP des entêtes IP envoyées = 0x00
- côté serveur :
flag DCSP des entêtes IP reçues = 0x00
flag DCSP des entêtes IP envoyées = 0x10 en début de session SSH, puis 0x08 lors du transfert SFTP
- entre la Livebox et le SFT
flag DCSP de toutes les entêtes IP = 0x00
Priorité "Best effort" dans les entêtes 802.1Q
(cf. image jointe)
La plupart du traffic qui traverse le routeur a un champ TOS à 0x00, c'est le cas par exemple d'un Speedtest.
SSH, par exemple, pour sa part, fixe le champ TOS pour un transfert de fichier à 0x20, les débits sont alors catastrophiques.
Si on utilise l'option SSH -o IPQoS=0x00 pour fixer le TOS à 0x00, on retrouve des débits normaux.
A mon sens cela veut donc dire que des équipements Orange surveillent / s'adaptent selon le champ TOS...
OK, forçons donc le TOS à 0x00 pour tous les paquets traversant le routeur :
iptables -t mangle -D POSTROUTING -j TOS --set-tos 0x00
Ça semble donc être ce que fait la Livebox !
-
ADSL Free de la premiere heure , passé à SFR Cable (400/40) en mode bridge via ERL3 et juste fibré Orange via ERL3, j'ai lu , j'ai lu , j'ai lu , et encore lu quasi toutes les pages traitant de la config MC220L + ERL3 + LB4 + mon LAN ,...et ca a l'air de marcher. J'ai un peu trebuche car le tuto de Nostra n'est pas super a jour ; vous m'avez fait des coups de chaud avec l'epopee du DHCP orange ( a suivre) et que le dyndns se met sur eth1.832 et pas sur eth1 ( oui une baffe je sais)… et d'autres petites tracasseries mais ca marche.
Alors je voulais vous dire : MERCI à tous et un special "hug" à ZOC
Cdt
-
- entre la Livebox et le SFT
flag DCSP de toutes les entêtes IP = 0x00
Priorité "Best effort" dans les entêtes 802.1Q
Excellent, merci pour ta confirmation !
Forcer le TOS à 0x00 est donc bien tout indiqué ;)
-
Pour information, depuis hier, je n'obtiens plus d'ipv4 avec la chaîne
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Mais ça marche avec la chaîne complète
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:3c:12:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:sa:lt:03:13:zz:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh:ha:sh
Le tout généré avec le script bash proposé dans ce thread par zoc https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg580713/#msg580713 (https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg580713/#msg580713)
-
voilà les logs de mon dhclient (bsd)
renew 4 2019/5/16 18:38:30;
rebind 5 2019/5/17 13:17:11;
expire 6 2019/5/18 17:46:53;
ça me laisse un petit temps pour mettre en place une solution (https://lafibre.info/images/smileys/pensif.gif) Merci de l'info! :o :o
-
Merci de l'info ;)
-
Le soucis de ne pas m'être penché là-dessus plus tôt :-\ C'est de l'anti-rejeu mais es-ce que la chaîne complète doit changer à chaque renew? Des gens ici la laissent encore statique? Merci d'avance ;)
-
bonjour,
j'utilise la chaîne courte sans mon mdp et j'ai obtenu une ip (v4 et v6) ce matin en rebootant ma machine.
pour l'ipv4:
renew 4 2019/05/16 22:49:24;
rebind 6 2019/05/18 12:07:14;
expire 0 2019/05/19 02:30:34;
on va garder un oeil là-dessus.
-
Il n’y a pas d’anti rejeu, j’ai la même chaîne longue (avec hash du mdp) depuis novembre.
-
Merci de vos réponses, je laisse expirer mon bail et je verrai bien si je récupère de nouveau ma v4 ou non. Je vous tiens informés ;)
Edit : dans les logs j'ai obtenu un nouveau bail depuis mon post d'hier. Il semble à priori qu'il n'y a pas (encore?) besoin de mettre la chaîne complète.
-
Hello à toutes et à tous.
en suivant vos indications et en allant chercher un peu ailleurs,
j'ai réussi à faire fonctionner ma Tinkerboard sous Debian à la place de ma LiveBox.
Cependant pour l'identifiant dhcp 90,
quand j'utilise le lien fourni dans ce topic https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/ (https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/) => ça fonctionne.
Par contre quand j'essaie d'utiliser le script fourni également dans ce topic
#!/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}) => Ca ne fonctionne pas.
Quelqu'un aurait un script fonctionnel, ou bien est ce moi qui suis mauvais :p ?
Merci par avance
-
Par contre quand j'essaie d'utiliser le script fourni également dans ce topic => Ca ne fonctionne pas.
Bonjour, En effet, les deux ne renvoient pas les mêmes chaînes de caractères. Le javascript de la page https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/ (https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/) renvoie toujours la même chaîne :
00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0D:66:74:69:2F:61:62:63:64:65:66:67:3c:12:31:32:33:34:35:36:37:38:39:30:31:32:33:34:35:36:03:13:41:86:08:90:50:a8:17:74:07:38:45:97:55:4a:5d:ee:34
Le bash renvoie la chaîne :
00:00:00:00:00:00:00:00:00:00:00:1A:09:00:00:05:58:01:03:41:01:0D:66:74:69:2f:61:62:63:64:65:66:67:3C:12:65:66:64:66:30:63:31:33:65:61:33:30:32:30:36:39:03:13:65:9c:83:54:7a:47:2d:e7:de:9a:cb:22:5c:cc:1f:8c:d3
Les 12 premiers caractères sont les mêmes que ceux générés par le javascript et constants puis, à chaque exécution du programme bash les 35 derniers caractères sont manifestement générés aléatoirement pour le login fti/abcdefg et le mot de passe hijklmn.
Pour répondre à ta question le programme bash fonctionne mais ne renvoie pas la même chaîne pour l'option 90. Ceci est dû à l'explication donnée dans cette page https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/ (https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/). À moins que depuis l'année dernière Orange ait changé sa procédure d'authentification.
Il faudrait que tu analyses la trame renvoyée par la Livebox au moment du démarrage, avec wireshark ou la commande tcpdump pour voir quelle chaîne de caractère Orange génère et identifier les caractères aléatoires à chaque redémarrage.
-
En pratique, ça fonctionne encore aujourd'hui sans la partie aléatoire dérivée du mot de passe, non ?
Mon routeur sous OpenWRT s'authentifie avec succès avec la chaîne de l'option 90 en dur, sous cette forme :
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:00000000000000000000001a0900000558010341010d6674692f71707138383838[/color]'
-
à chaque exécution du programme bash les 35 derniers caractères sont manifestement générés aléatoirement pour le login fti/abcdefg et le mot de passe hijklmn.
Oui, c'est pour obtenir un comportement le plus proche possible de ce que fait la box. D'ailleurs, seule une partie est aléatoire et sert de sel pour le hachage du login+mot de passe (protocole CHAP similaire à ce qui existe sur PPP). Cette seconde partie dépend donc du sel et n'est donc pas aléatoire (sel identique = hash identique).
Accessoirement, vu que c'est moi qui ait écrit le script bash, je tiens à préciser (et je crois que je l'avais déjà fait) que je ne l'ai utilisé chez moi (j'ai récupéré ma chaine d'identification avec tcpdump directement sur le port WAN de ma LB). Par contre au moins une personne a confirmé que la chaine générée fonctionnait chez lui.
-
Hello.
Merci pour vos réponses.
En tout cas ton script est super balèze.
J'aimerais savoir en faire.
Je l'etudierai ce weekend pour essayer de le comprendre.
Pour ma chaîne générée.je vais retenter le coups et faire ce que tu m'as propose.
Merci encore
-
Hello.
Merci pour vos réponses.
En tout cas ton script est super balèze.
J'aimerais savoir en faire.
Je l'etudierai ce weekend pour essayer de le comprendre.
Pour ma chaîne générée.je vais retenter le coups et faire ce que tu m'as propose.
Merci encore
Hello, pour vulgariser un peu le code, dans ses grandes lignes :
r=$(dd if=/dev/urandom bs=1k count=1 2>&1 | md5sum | cut -c1-16)
récupération d'un pseudo-aléatoire généré par le système, hashage en md5 de la valeur.
id=${r:0:1}
Création d'un salt (pas compris la structure)
h=3C12$(tohex ${r})0313$(tohex ${id})$(echo -n ${id}${pass}${r} | md5sum | cut -c1-32)
Création de la partie dynamique de l'option DHCP 90 d'Orange, avec des parties "fixes", mélangées au random précédent, et du salt accompagnant le mot de passe de l'abonnement Orange.
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})
Affichage de la chaîne finale, avec les octets communs au début, et la partie mobile (variable h) de la chaîne générée juste avant.
enfin le niveau technique pour faire un script comme celui-ci, est impressionnant. Bravo!
-
Merci pour les explications.
😀😀
-
Hello, pour vulgariser un peu le code, dans ses grandes lignes :
récupération d'un pseudo-aléatoire généré par le système, hashage en md5 de la valeur.Création d'un salt (pas compris la structure)Création de la partie dynamique de l'option DHCP 90 d'Orange, avec des parties "fixes", mélangées au random précédent, et du salt accompagnant le mot de passe de l'abonnement Orange.Affichage de la chaîne finale, avec les octets communs au début, et la partie mobile (variable h) de la chaîne générée juste avant.
enfin le niveau technique pour faire un script comme celui-ci, est impressionnant. Bravo!
Je te remercie encore pour tes explications.
Par rapport à ce générateur :https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/ (https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/) :
La partie id=${r:0:1} serait l'équivalent du Salt du générateur graphique.
Mais dans le générateur du lien que j'ai mis en haut : La partie Byte sert à quoi et elle est représentée où dans le script.
Merci encore
-
Pour les curieux, il faut lire la référence, la rfc 3118 (https://tools.ietf.org/html/rfc3118 (https://tools.ietf.org/html/rfc3118) ), qui nous renseigne sur l'option 90.
-
Orange ne respecte pas la RFC 3118 : ils utilisent les options DHCP v4 90 (Authentication) et DHCP v6 11 (OPTION_AUTH) qui sont effectivement allouées pour l’authentification du client auprès du serveur DHCP mais le contenu (sorte d'authentification PPP CHAP MD5 avec l'Id et le Salt générés aléatoirement par le client) est spécifique à Orange probablement pour mutualiser l'authentification avec les serveurs Radius utilisés pour les accès PPPoX (ADSL).
-
Oui, c'est pour obtenir un comportement le plus proche possible de ce que fait la box. D'ailleurs, seule une partie est aléatoire et sert de sel pour le hachage du login+mot de passe (protocole CHAP similaire à ce qui existe sur PPP). Cette seconde partie dépend donc du sel et n'est donc pas aléatoire (sel identique = hash identique).
Accessoirement, vu que c'est moi qui ait écrit le script bash, je tiens à préciser (et je crois que je l'avais déjà fait) que je ne l'ai utilisé chez moi (j'ai récupéré ma chaine d'identification avec tcpdump directement sur le port WAN de ma LB). Par contre au moins une personne a confirmé que la chaine générée fonctionnait chez lui.
Méa culpa :) :) :) :)
Ton script fonctionne, et je dirais même très très très bien. ;D ;D ;D ;D
Je faisais une erreur monstrueuse quand je l'essayais :
Au lieu de mettre:
login='fti/ID'
pass='PASS'
je mettais:
login=fti/ID
pass=PASS
J'ai négligeais les apostrophes.
-
Bonjour,
Quelqu'un a-t-il déjà demandé officiellement à Orange les différents protocoles nécessaires à la connexion ?
-
Muhmm, il faudrait pouvoir trouver un contact chez Orange compétant pour répondre (sûrement pas au SC).
Et puis, il n'est pas obligé de répondre puisque le client (surtout particulier) est censé utiliser la box fournie par l’opérateur.
-
Orange n'a jamais rien donné de manière officielle, et je ne pense pas qu'Orange le fasse un jour, sauf à y être contraint (ce qui ne serait pas si mal).
L'accès est censé se faire via la LB, qui est prévue pour un usage grand-public. C'est d'ailleurs pour ça qu'on se démène à la remplacer.
Edit : au passage, je suis toujours connecté via la chaîne sans partie aléatoire de l'option 90. ras.
-
Hello,
Quelqu'un a-t-il essayé et réussi à mettre en place un serveur DHCP sous Linux qui vu d'une Livebox, fonctionne grossièrement de la même manière que les serveurs d'Orange ?
-
Méa culpa :) :) :) :)
Ton script fonctionne, et je dirais même très très très bien. ;D ;D ;D ;D
Je faisais une erreur monstrueuse quand je l'essayais :
Au lieu de mettre:
login='fti/ID'
pass='PASS'
je mettais:
login=fti/ID
pass=PASS
J'ai négligeais les apostrophes.
À moins d'avoir des caractères spéciaux du bash dans le mot de passe ou dans le login, j'aurai juré que les deux versions du scripts sont équivalentes.
Avait-on des caractères spéciaux ?
-
Oui, je n’ai pas non plus compris pourquoi l’ajout des apostrophes a résolu le problème.
Il n’y a pas de caractères spéciaux normalement dans le mot de passe (genre un $ pourrait poser problème et obliger à mettre des apostrophes), et le ‘/‘ du login n’est pas un caractère spécial pour bash.
-
Quelqu'un a-t-il essayé et réussi à mettre en place un serveur DHCP sous Linux qui vu d'une Livebox, fonctionne grossièrement de la même manière que les serveurs d'Orange ?
J’ai prévu de le faire (pour pouvoir tester des configs sans devoir débrancher mon routeur), je pense pas qu’il y ait de difficultés pour le serveur DHCP, Les VLANs c’est enfantin, mes seuls problèmes pour l’instant:
- Filtrer les requêtes DHCP qui ne sont pas en CoS 802.1p 6
- Trouver du temps pour le faire ;)
Accessoirement, chez beaucoup d’entre nous, la Livebox est conservée pour la téléphonie, et donc le routeur de remplacement fait déjà serveur DHCP pour elle (Il y a juste encore une fois la CoS qu’on ne réplique pas car elle n’est pas obligatoire coté box).
-
Oui, je n’ai pas non plus compris pourquoi l’ajout des apostrophes a résolu le problème.
Alors, nous sommes d'accord ;-)
À ma connaissance, tous les logins et mots de passe d'Orange n'utilisent que des lettres (minuscules) et chiffres : les apostrophes devraient être facultatives;
-
J’ai prévu de le faire (pour pouvoir tester des configs sans devoir débrancher mon routeur), je pense pas qu’il y ait de difficultés pour le serveur DHCP, Les VLANs c’est enfantin, mes seuls problèmes pour l’instant:
- Filtrer les requêtes DHCP qui ne sont pas en CoS 802.1p 6
- Trouver du temps pour le faire ;)
J'imaginais quelque chose:
Internet --- Serveur DHCP simulé --- Switch --- Livebox ou Routeur de remplacement --- PC
Dans ce cas, le marquage 802.1p pourrait s'opérer au niveau du switch.
À creuser.
-
J'imaginais quelque chose:
Internet --- Serveur DHCP simulé --- Switch --- Livebox ou Routeur de remplacement --- PC
Si j'ai bien compris, dans le schéma ci-dessus, un serveur DHCP supportant la RFC3118 sera a minima utile.
Serait-ce indispensable ?
Quel serveur DHCP sous Linux supportent la RFC3118, au moins avec une configuration manuelle ?
-
Si j'ai bien compris, dans le schéma ci-dessus, un serveur DHCP supportant la RFC3118 sera a minima utile.
Serait-ce indispensable ?
Il faut juste que le serveur DHCP retourne les options que la Livebox attend.
En pratique, sous OpenWRT, ça donne par exemple ça (fichier /etc/config/dhcp) :
config dhcp 'TEL'
option start '100'
option leasetime '12h'
option domain 'orange.fr'
option limit '150'
option interface 'TEL'
list dhcp_option '120,00:06:73:62:63:74:33:67:03:52:45:4e:06:61:63:63:65:73:73:11:6f:72:61:6e:67:65:2d:6d:75:6c:74:69:6d:65:64:69:61:03:6e:65:74:00'
list dhcp_option '125,00:00:05:58:0c:01:0a:00:01:00:00:00:ff:ff:ff:ff:ff'
list dhcp_option '90,00:00:00:00:00:00:00:00:00:00:00:64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30'
list dhcp_option '119,REN.access.orange-multimedia.net'
list dhcp_option '15,orange.fr'
-
Oui, mais si on veut émuler au mieux le serveur DHCP d'Orange (afin de pouvoir tester d'autres routeurs sans avoir à le connecter à la ligne FTTH par exemple), alors ce n'est pas suffisant: Le serveur DHCP ne doit pas répondre si le client ne répond pas aux exigences d'Orange (chaine d'auth, vendor name, etc...).
-
Effectivement, je n'avais pas bien lu le cahier des charges ;D
-
C'est corrigé avec la stanza pre-up, qui est exécutée avant les handshakes:
# WAN vlan 832 internet
auto enp1s0.832
iface enp1s0.832 inet dhcp
pre-up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
iface enp1s0.832 inet6 dhcp
pre-up ip link set enp1s0.832 type vlan egress 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
request_prefix 1
accept_ra 2
J'ai lu que le DHCP exigeait des raws sockets par opposition à des BSD/UDP sockets (cf [1]).
Les SKB de Linux sont-ils du type raw, BSD/UDP ou encore autre chose ?
Le client ISC DHCP officiel de Debian utilise-t-il les SKB ?
[1] https://kb.isc.org/docs/aa-00378 (https://kb.isc.org/docs/aa-00378)
-
Les SKB de Linux sont-ils du type raw, BSD/UDP ou encore autre chose ?
Un SKB n'est pas un socket en soi. C'est la structure de données (buffer) utilisé par le noyau Linux pour stocker/manipuler un socket donc ca concerne tout les sockets y compris les raw. C'est cette structure qui est envoyé/recu au driver de la carte réseau.
Le client ISC DHCP officiel de Debian utilise-t-il les SKB ?
directement non. Le code est portable (pas que pour Linux) donc utilise les appels systèmes standardisés BSD/POSIX (notamment socket(2) (http://man7.org/linux/man-pages/man2/socket.2.html)).
Sur Linux et Linux seulement un socket BSD/POSIX est mis en oeuvre en utilisant un skb dans le noyau. Mais le code d'ISC DHCP n'étant pas spécifique a Linux a aucun moment on ne voit cela. Apres rien n’empêche d'aller bidouiller le code.
-
Merci pour cette réponse.
Dans le doc [1], on peut lire que les paramètres suplèmentaires ingress-qos-map et egress-qos-map existent pour les VLAN.
On peut aussi lire une référence au paramètre egress.
Où peut-on trouver la définition de ce dernier paramètre egress, qui justement figure dans les exemples de config de ce fil de discussion ?
S'agit-il simplement d'une notation abrégée de egress-qos-map ?
[1] https://manpages.debian.org/experimental/iproute2/ip-link.8.en.html (https://manpages.debian.org/experimental/iproute2/ip-link.8.en.html)
-
Un SKB n'est pas un socket en soi. C'est la structure de données (buffer) utilisé par le noyau Linux pour stocker/manipuler un socket donc ca concerne tout les sockets y compris les raw. C'est cette structure qui est envoyé/recu au driver de la carte réseau.
directement non. Le code est portable (pas que pour Linux) donc utilise les appels systèmes standardisés BSD/POSIX (notamment socket(2) (http://man7.org/linux/man-pages/man2/socket.2.html)).
Sur Linux et Linux seulement un socket BSD/POSIX est mis en oeuvre en utilisant un skb dans le noyau. Mais le code d'ISC DHCP n'étant pas spécifique a Linux a aucun moment on ne voit cela. Apres rien n’empêche d'aller bidouiller le code.
Sur Linux, comment s'assure-t-on alors que le client ISC DHCP èmette des requètes avec une priorité de 6 pour complaire aux serveurs d'Orange ?
En insérant un équipement intermédiaire qui va forcer cette priorité ou bien par une configuration idoine du réseau ?
(initialement, le paramètre "vlan egress ..." m'avait laissé pensé qu'un équipement réseau intermédiaire n'était pas nécessaire mais en relisant plusieurs la réponse ci-dessus, je pense que je n'ai pas la réponse)
-
(initialement, le paramètre "vlan egress ..." m'avait laissé pensé qu'un équipement réseau intermédiaire n'était pas nécessaire mais en relisant plusieurs la réponse ci-dessus, je pense que je n'ai pas la réponse)
Je partage l'avis de M. olivier2831, la réponse de M. kgersen paraît savante mais est claire comme du jus de boudin. Pourriez-vous donner une explication plus simple pour les nombreux néophytes comme moi inscrits à ce forum ?
-
Sur Linux, comment s'assure-t-on alors que le client ISC DHCP èmette des requètes avec une priorité de 6 pour complaire aux serveurs d'Orange ?
voici ma réponse de l'année dernière (je me re-cite), j'essaie d'être aussi clair que possible:
3. DHCP
est géré par des programmes genre ISC-DHCP client/server, ou autres, qui sont TOUS obligés d'utiliser des sockets "SO_PACKET" (appelés RAW par certains) pour forger des paquets IP/DHCP corrects.
Ces sockets "SO_PACKET" sont hookées en egress de telle sorte que netfilter ne puisse pas agir dessus (ni les filtrer, ni modifier les paquets).
Pour ceux qui utilisent ISC DHCP client, ce dernier NE PERMET PAS de configurer une meta priorité (skbuff priority).
Il faut donc modifier son code source pour envouyer les bons meta priorité et DSCP...
Ensuite, le map egress 802.1q fait le reste.
Si quelqu'un est interessé par le patch, il est très simple à faire.
-
j'essaie d'être aussi clair que possible
C'est limpide.
-
voici ma réponse de l'année dernière (je me re-cite), j'essaie d'être aussi clair que possible:Si quelqu'un est interessé par le patch, il est très simple à faire.
Ce fil de discussion est déjà long et ce n'est pas facile d'en avoir en tête les principaux éléments :
merci infiniment pour cette précision !
En l'absence sous Linux (est-ce bien exact avec Debian Buster ?) de client ou serveur DHCP intégrant la configurant la priorité DSCP, je configurerai cette priorité sur un équipement intermédiaire (une autre machine Linux, un switch Mikrotik ou autre).
-
En l'absence sous Linux (est-ce bien exact avec Debian Buster ?) de client ou serveur DHCP intégrant la configurant la priorité DSCP, je configurerai cette priorité sur un équipement intermédiaire (une autre machine Linux, un switch Mikrotik ou autre).
https://www.3cx.com/blog/voip-howto/qos-linux/ (https://www.3cx.com/blog/voip-howto/qos-linux/)
C'est pour la VoIP, mais on peut l'adapter.
-
https://www.3cx.com/blog/voip-howto/qos-linux/ (https://www.3cx.com/blog/voip-howto/qos-linux/)
C'est pour la VoIP, mais on peut l'adapter.
Ca ne marchera pas, DHCP client coutourne netfilter entièrement avec sa socket SO_PACKET.
Les trames générées avec les sockets SO_PACKET sont injectées directement dans la couche "egress".
Pour ceux qui se demandent désespérèment pourquoi DHCP client, Dibbler, Wide DHCP et Cie, la raison vient de la bizarrerie du DHCP (ipv4).
Les demandes initiales sont émises avec une addresse IP source "0.0.0.0". C'est normalement interdit par la pile IP linux.
D'où l'utilisation d'une SO_PACKET pour générer ces messages.
IPv6 n'a pas ce problème, DHCP client n'utilise pas de SO_PACKET en ipv6, et on peut altérer (mangle) les trames avec netfilter.
-
Bonjour,
Ca fait un bail que je ne suis pas repassé sur ce topic. Quand ce changement d'option était apparu, il était évoqué le risque que la dernière partie de la chaine puisse être "aléatoire", et changeante, ce qui éliminerait la plupart des routeurs persos.
Est-ce devenu le cas, ou alors l'authentification fonctionne toujours avec une chaine "fixe" ?
Merci : )
-
bonjour,
ici, ça roule toujours avec une chaîne fixe. J'ai même pas encodé le mdp dans la chaîne, et tant que ça fonctionne, je touche pas :)
Jerem
-
Ca ne marchera pas, DHCP client coutourne netfilter entièrement avec sa socket SO_PACKET.
Les trames générées avec les sockets SO_PACKET sont injectées directement dans la couche "egress".
Pour ceux qui se demandent désespérèment pourquoi DHCP client, Dibbler, Wide DHCP et Cie, la raison vient de la bizarrerie du DHCP (ipv4).
Les demandes initiales sont émises avec une addresse IP source "0.0.0.0". C'est normalement interdit par la pile IP linux.
D'où l'utilisation d'une SO_PACKET pour générer ces messages.
IPv6 n'a pas ce problème, DHCP client n'utilise pas de SO_PACKET en ipv6, et on peut altérer (mangle) les trames avec netfilter.
Je pense que la suggestion d'Iznogoud est correctes car elle s'applique aux équipements réseaux intermédiaires (switch) entre le client DHCP et son serveur: dans l'équipement intermédiaire, le trafic DHCP est manipulable normalement.
-
bonjour,
ici, ça roule toujours avec une chaîne fixe. J'ai même pas encodé le mdp dans la chaîne, et tant que ça fonctionne, je touche pas :)
Jerem
Merci pour l'info : )
Par contre j'y pense, si je retourne chez Orange, j'aurais une livebox 4 et donc pas d'ONT, directement un sfp dans la box non ? : /
-
si je retourne chez Orange, j'aurais une livebox 4 et donc pas d'ONT, directement un sfp dans la box non ? : /
pas nécessairement. En avril quand j'ai fait installé une offre sosh a quelqu'un, on a reçu une livebox 4 et un ont. va savoir pourquoi ...
après, ça peut se faire changer au sc ou acheter un MC220L.
Jerem
-
Ca ne marchera pas
Tu as essayé ?
-
Tu as essayé ?
oui, c'est pour ça que je répond.
Les messages DHCPv4 envoyés par ISC DHCP ne sont pas vus par netfilter, parce qu'une socket PACKET est utilisée par ISC DHCP client.
C'est assez simple à tester, donc STP vérifie par toi même ;)
-
pas nécessairement. En avril quand j'ai fait installé une offre sosh a quelqu'un, on a reçu une livebox 4 et un ont. va savoir pourquoi ...
après, ça peut se faire changer au sc ou acheter un MC220L.
Jerem
Merci beaucoup. J'ai un switch avec des ports sfp dispo, mais je ne trouve pas d'info sur sa compatiblité. Pour assurer le coup, je vais commander le MC220L, vu son prix, ça ira même s'il ne sert à rien. Désolé d'avoir fait du HS sur cette partie.
Bonne journée à tous !
-
Bonjour à toutes et tous,
Je tente une configuration OPNSense avec toutes les informations trouvées dans ce post et dans les autres très nombreuses informations sur ce sujet.
Et pourtant en reportant les données issues d'une capture sous WIRESHARK de ma livebox 3, je ne parviens pas à obtenir une adresse IP Publique de la part de Orange.
Je pense avoir saisi les bons paramètres, mais je recherche un peu d'aide pour vérifier que je ne me suis pas trompé.
Il y aurait-il encore des nouveautés chez Orange qui complexifieraient les informations à fournir dans la configuration des DHCP V4 et V6.
J'ai scrupuleusement suivi les tutos ...
Merci par avance de vos précieuses suggestions pour me permettre d'avancer.
Les données de DHCP V6 ici
DHCP V6
ia-pd 0,raw-option 6 00:0b:00:11:00:17:00:18,
raw-option 15 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33,
raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d,
raw-option 11 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:66:74:69:2f:78:68:70:39:68:32:71:3c:12:5f:59:33:27:28:65:67:22:49:54:3b:2b:31:6a:63:4a:03:13:57:a9:a8:7e:7f:8e:e4:75:82:c5:84:3c:df:c4:d0:87:a0
J'ai réactivé le DHCP V6 et entré les bons paramètres depuis mes derniers essais mais rien ne parvient à faire obtenir une adresse.
Les échanges de trames s'arrêtent à des demandes côtés OPNSense mais pas de réponse du côté Orange.
Je me demande aussi s'il n'y a pas un endroit comme avec OPENWRT où on doit renseigner l'@Mac de l'interface WAN
-
La COS 802.1p du VLAN 832 est bien configurée à 6 pour les requêtes DHCP ?
(Je n’utilise pas OPNsense, donc aucune idée de comment on fait).
-
Bonjour zoc, je pense que tu parles du pcp, j'ai essayé 0 Best effort et 6 inter network, rien dans les deux cas.
Je suis un peu perdu.
Comment chercher progressivement avec une méthode support.
-
Bonjour a tous
Est ce que quelqu'un pourrait faire un resumé a jour des differents parametres à mettre en place pour se separer de la livebox ? Pour ipv4 et v6
J'ai a titre perso une livebox 5 fraichement installée. J'ai demandé l'ont au gars qui est venu poser le cable. C est un huawei.
Impossible de la faire monter le lien en dhcp vlan 32 sous mikrotik. On trouve tout et n' importe quoi sur le net comme parametres, idem pour la cos 6... Difficile donc de s'y retrouver !
D'autre part le pppoe vlan 835 marche toujours parfaitement si ce n'est une petite baisse de debit.
Merci pour votre aide
-
Bonjour a tous
Est ce que quelqu'un pourrait faire un resumé a jour des differents parametres à mettre en place pour se separer de la livebox ? Pour ipv4 et v6
J'ai a titre perso une livebox 5 fraichement installée. J'ai demandé l'ont au gars qui est venu poser le cable. C est un huawei.
Impossible de la faire monter le lien en dhcp vlan 32 sous mikrotik. On trouve tout et n' importe quoi sur le net comme parametres, idem pour la cos 6... Difficile donc de s'y retrouver !
D'autre part le pppoe vlan 835 marche toujours parfaitement si ce n'est une petite baisse de debit.
Merci pour votre aide
Bonsoir à tous,
J'ai actuellement une Livebox 5 sur un OpenJet Fibre 100Go et une Livebox Pro v4 avec ONT sur une offre Fibre basique.
J'ai commandé un Mikrotik hEX S et un hEX POE et également 2 SFP Sercomm...
Quelqu'un pourrait faire un résumé à jour comment on génère l'option 90 à aujourd'hui et si cela est un outil en ligne comme celui de https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/ on mets quoi dans les champs à remplir (Salt et Byte) ? Est ce que les valeurs pré-remplies à l'affichage sont les bonnes (si on est sur la bonne box bien sur) ?
Merci d'avance.
Nicolas
-
Sur le HEX s tu nauras pas la possibilité de fixer a 6 la cos de facon hardware via le switch rule.
-
on mets quoi dans les champs à remplir (Salt et Byte) ?
Des valeurs random de la meme taille que les valeurs par défaut.
L'authentification d'Orange utilise une "pseudo" méthode CHAP, à la différence que dans du vrai CHAP, Salt et Byte sont fournis par le serveur (impossible à faire en DHCP), alors que là c'est la box elle même qui les génère aléatoirement et les envoient au serveur DHCP en même temps que le résultat du hachage du Salt+Byte+login+passwd.
Sinon, bonne chance pour faire reconnaitre les SFP Sercomm par Orange...
-
Sur le HEX s tu nauras pas la possibilité de fixer a 6 la cos de facon hardware via le switch rule.
Merci pour la remarque, du coup j'ai annulé ma commande du hEX S et j'ai gardé le Hex PoE.
-
Bonjour à toutes et tous,
Je tente une configuration OPNSense avec toutes les informations trouvées dans ce post et dans les autres très nombreuses informations sur ce sujet.
Et pourtant en reportant les données issues d'une capture sous WIRESHARK de ma livebox 3, je ne parviens pas à obtenir une adresse IP Publique de la part de Orange.
Je pense avoir saisi les bons paramètres, mais je recherche un peu d'aide pour vérifier que je ne me suis pas trompé.
Il y aurait-il encore des nouveautés chez Orange qui complexifieraient les informations à fournir dans la configuration des DHCP V4 et V6.
J'ai scrupuleusement suivi les tutos ...
Merci par avance de vos précieuses suggestions pour me permettre d'avancer.
Les données de DHCP V6 ici
DHCP V6
ia-pd 0,raw-option 6 00:0b:00:11:00:17:00:18,
raw-option 15 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33,
raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d,
raw-option 11 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:01:0d:66:74:69:2f:78:68:70:39:68:32:71:3c:12:5f:59:33:27:28:65:67:22:49:54:3b:2b:31:6a:63:4a:03:13:57:a9:a8:7e:7f:8e:e4:75:82:c5:84:3c:df:c4:d0:87:a0
J'ai réactivé le DHCP V6 et entré les bons paramètres depuis mes derniers essais mais rien ne parvient à faire obtenir une adresse.
Les échanges de trames s'arrêtent à des demandes côtés OPNSense mais pas de réponse du côté Orange.
Je me demande aussi s'il n'y a pas un endroit comme avec OPENWRT où on doit renseigner l'@Mac de l'interface WAN
Bonjour, le tutoriel que vous avez suivi ce me semble qui est bien documenté concerne la LB4.
Je dirai qu'il faudrai appliquer les options de celui la.
https://wiki.opnsense.org/manual/how-tos/orange_fr_fttp.html
N'hésitez pas à me faire part de votre retour
-
Livebox 3, 4 ou 5 la méthode d'authentification est strictement la même.
D'ailleurs Orange ne vérifie pas si la version de la box que vous spécifiez dans l'option 15 (IPv6) ou user-class (IPv4) correspond à la box que vous avez. J'ai oublié pendant très longtemps de remplacer "Livebox3" par "Livebox4" (longtemps = plusieurs mois) quand je suis passé de la LB3 à la LB4 (pour avoir le nouveau décodeur 4K à l'époque).
-
Bonjour,
J'ai suivi les infos de ce thread. J'ai reussi à setup correctement l'IPv4 et obtenir une adresse de la part d'orange. Pour IPv6 on ne m'attribut aucune adresse.
Est-ce que parmi vous certain on réussi ? Si oui qu'elle réglage/option avait vous utilisé.
J'utilise Opnsense
-
DHCPv6-PD n’attribue pas d’adresse mais un préfixe (d’où son nom), donc c’est normal que tu n’ais pas d’IP. C’est à toi de te débrouiller avec ton range.
-
Et comment je fais pour voir si j'ai bien reçu une range ? Et par ailleurs voir ça valeur.
-
Voici la configuration que j'ai en IPv6 après avoir suivi la doc de opnsense pour Orange
-
Il y a un sujet propre a opnsense: https://lafibre.info/remplacer-livebox/opnsense-remplacer-livebox-aucune-modification-necessaire/
-
J'ai posté sur ce topic, car je ne pense pas que ça vienne de Opnsense. Je voulais savoir si d'autre avait un probleme pour l'IPv6. Quand je capture les paquets je vois des requettes DHCPv6 mais pas de réponse de la part de orange
-
Si pas de réponse, c'est qu'il y a un problème de conf. Ou la COS qui n'est pas à 6 ?
-
Ok mon soucis était que la priorité du VLAN était à Best Effort (0) comme indiqué dans la doc de OpnSense, ensuite dans la configuration de l'interface WAN j'avais mis VLAN Priority à 6 mais il semblerait que ça n'ait pas d'effet. Une fois que j'ai passé la priorité du VLAN à 6, j'ai directement reçu un IPv6.
Merci pour le tips ;)
-
Quelqu'un pourrait faire un résumé à jour comment on génère l'option 90 à aujourd'hui et si cela est un outil en ligne comme celui de https://jsfiddle.net/kgersen/3mnsc6wy/embedded/result/ on mets quoi dans les champs à remplir (Salt et Byte) ? Est ce que les valeurs pré-remplies à l'affichage sont les bonnes (si on est sur la bonne box bien sur) ?
Merci d'avance.
Nicolas
Notre ami ZOC a réalisé un script bash pour générer l'option 90 qui est parfait.
#
!/bin/bash
login='fti/*******'
pass='****************'
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})
Le sauver sous le nom option90.sh par exemple, lui donner les droits d'exécution, et copier la chaîne de caractères donnée en résultat.
-
Notre ami ZOC a réalisé un script bash pour générer l'option 90 qui est parfait.
#
!/bin/bash
login='fti/*******'
pass='****************'
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})
Le sauver sous le nom option90.sh par exemple, lui donner les droits d'exécution, et copier la chaîne de caractères donnée en résultat.
Bonjour,
Sur mes derniers tests avec un Mikrotik on a plus besoin du password seulement du login après la partie fti/ et j'ai utilisé le site https://www.rapidtables.com/convert/number/ascii-to-hex.html
et j'ai ajouté le résultat à la chaine 0x00000000000000000000001a0900000558010341010d6674692FXXXXXXXXXXXXXX en remplaçant les XX par le résultat du site, j'envoi cette chaine pour l'option 90 en IPv4 et Option 11 en IPv6 ca marche nickel...
-
Ça marche « encore pour l’instant » sans le mot de passe tu veux dire... Le but d’Orange à terme c’est vraiment de vérifier le mot de passe également.
Les utilisateurs de la chaîne « courte » doivent vraiment s’attendre à se retrouver sans connexion tôt ou tard.
-
Ça marche « encore pour l’instant » sans le mot de passe tu veux dire... Le but d’Orange à terme c’est vraiment de vérifier le mot de passe également.
Les utilisateurs de la chaîne « courte » doivent vraiment s’attendre à se retrouver sans connexion tôt ou tard.
Bonjour Zoc,
Sur mes deux accès Orange et Orange Pro (avec aujourd'hui une Livebox 5 et une Livebox Pro v4) et avec les captures que j'ai pu faire dans tous les sens j'ai bien que le login sur l'option 90 et ca suffit pour que cela fonctionne avec ou sans Livebox
-
Ce n'est pas parce que cela marche aujourd'hui que cela marchera encore demain.
-
Bonjour,
Sur mes derniers tests avec un Mikrotik on a plus besoin du password seulement du login après la partie fti/ et j'ai utilisé le site https://www.rapidtables.com/convert/number/ascii-to-hex.html
et j'ai ajouté le résultat à la chaine 0x00000000000000000000001a0900000558010341010d6674692FXXXXXXXXXXXXXX en remplaçant les XX par le résultat du site, j'envoi cette chaine pour l'option 90 en IPv4 et Option 11 en IPv6 ca marche nickel...
Sans vous offenser, je n'ai pas bien compris la question. Si vous savez comment générer la chaîne de caractères de l'option 90, pourquoi demander si quelqu'un peut faire un résumé à jour comment on génère l'option 90 :)
-
Sans vous offenser, je n'ai pas bien compris la question. Si vous savez comment générer la chaîne de caractères de l'option 90, pourquoi demander si quelqu'un peut faire un résumé à jour comment on génère l'option 90 :)
Bonjour,
J'avais demandé un résumé parce qu'en parcourant le forum on s'aperçoit qu'il y a mille et une façons de faire et je voulais avoir la dernière version à jour. avant de me lancer..
Suite aux tests que j'ai fait j'ai posté comment j'ai réussi à me connecter grace à toutes les informations postées sur le forum !
-
bonjour,
depuis une coupure réseau hier soir, je narrive plus a obtenir d'ipv4 avec mon routeur linux. l'ipv6 lui fonctionne toujours. mon ancienne ipv4 a d'ailleurs été réatribuer très rapidement a un autre abonné (vu par mon monitoring qui me dit que mon ancienne ipv4 ping).
j'utilisais la chaine d'identification dite courte, donc sans le mot de passe. pour être sûr, j'ai utilisé le script bash de zoc qui génère le tout avec le mot de passe, le dhcp d'orange ne me répond pas non plus... Par contre, avec une livebox, ça fonctionne ...
j'ai fait un tcpdump n'arrivant pas à faire un tshark de la livebox, et ça donne ça:
0x0170: 0000 0000 0000 0000 0000 1a09 0000 0558 ...............X
0x0180: 0103 4101 0d66 xxxx 2f68 xxxx 7433 6b68 ..A..fti/xxxxxxx
0x0190: 3c12 3c57 3052 5776 6e7b 435b 2337 4437 <.<W0RWvn{C[#7D7
0x01a0: 7224 0313 3274 a9ea b4bf 6498 9165 d59c r$..2t....d..e..
0x01b0: e60c 4568 a0ff ..Eh..
en tentant de le faire avec tshark, j'ai une erreur du genre:
Option: (90) Authentication
Length: 70
Protocol: configuration token (0)
Algorithm: 0
Replay Detection Method: Monotonically-increasing counter (0)
RDM Replay Detection Value: 0x0000000000000000
Authentication Information: \032\t
[Expert Info (Warning/Undecoded): Trailing stray characters]
[Trailing stray characters]
[Severity level: Warning]
[Group: Undecoded]
Option: (255) End
l'option générée, ressemble à ça:
00:00:00:00:00:00:00:00:00:00:00:1A:09:00:00:05:58:01:03:41:01:0D:66:74:69:2f:xx:xx:xx:xx:xx:6b:xx:3C:12:35:62:38:33:34:32:30:61:64:35:39:34:32:36:33:33:03:13:35:0c:be:95:ed:f0:b0:df:61:8c:a2:7b:1d:28:6a:43:cb
est-ce que je loupe un truc ?
merci beaucoup,
Jerem
P.S: les outils de captures accessibles ça ne court pas les rue.
P.S2 : au pire je vais demander l'envoi de mon mot de passe pour être sûr.
-
Même chose pour moi, j'ai perdu l'IPv4 dans la nuit. Je n'accède plus qu'aux sites en IPv6 (dont celui-ci, heureusement !).
-
Juste pour info: ça marche encore chez moi (avec la version longue de l'option 90). Dernier renouvellement DHCP sans problème ce matin (28/10) à 6:49:
Oct 28 06:49:04 router dhclient[223583]: DHCPREQUEST for 86.aaa.bbb.ccc on eth1.832 to 80.10.247.176 port 67
Oct 28 06:49:04 router dhclient[223583]: DHCPACK of 86.aaa.bbb.ccc from 80.10.247.176
Oct 28 06:49:05 router dhclient[223583]: bound to 86.aaa.bbb.ccc -- renewal in 80374 seconds.
-
Bonjour,
Même problème pour moi (dans le 92). Plus d'IPv4 depuis cette nuit, mais IPv6 fonctionne toujours.
J'étais déjà sur l'option longue. J'ai essayé de la régénérer avec le script de zoc, mais pas plus de succès :(
-
Je suis moi aussi déjà sur l'option longue. Je n'ai pas essayé de la regénérer. Je suis aussi dans le 92.
-
hello,
idem ici dans le 68, ipv4 perdue tot ce matin vers 05:30.
-
Je ne pense pas que ce soit du aux options DHCP.
J'ai le même problème. Ma box me colle un wan_03_3001.
et globalement, il semble que ce soit une panne générale d'orange :
https://downdetector.fr/statut/orange/
(PS: je suis sur courbevoie)
-
Panne générale c'est possible mais étrange, la livebox en direct fonctionne
-
Vous êtes sur que votre box ne fallback pas en PPPoE ?
Il y a a priori un gros incident dans le 92, même si je ne vois pas pourquoi IPv6 (et IPv4 en PPPoE éventuellement) ne serait pas aussi impacté...
-
pour info avec la livebox (dans le 78) :
4.1
Statut de la connexion internet
Actif
4.2
Nom d'utilisateur
fti/*******
4.3
Dernière connexion
28 octobre 2020, 09 h 58 m
4.4
Durée de la connexion
19 m 27 s
4.5
Type du protocole
PPP
4.6
Code d'erreur de la dernière connexion
ERROR_NONE
4.7
Date de la dernière connexion
28 octobre 2020, 09 h 58 m
4.8
ATM VP/VC ou VLAN
835
4.9
Taille MTU
1492
-
Hier j'avais des problèmes internet+wifi vers 23h30/00h00. Je cherche, pas de DNS, des problèmes sur mon serveur DNS/AD/VPN... puis je regarde mon EdgeRouter et plus d'IPv4 hier vers minuit.
Je me dis "problème sur la ligne ?", à priori non sur le site Orange alors :
Disable/Enable sur l'interface eth1.832 puis eth1 --> NOK
Redémarrage du routeur --> OK
Tout fonctionne nickel après reboot
-
je confirme que ma livebox bien que connectée...
4.5 Type du protocole PPP
-
Vous êtes sur que votre box ne fallback pas en PPPoE ?
Il y a a priori un gros incident dans le 92, même si je ne vois pas pourquoi IPv6 (et IPv4 en PPPoE éventuellement) ne serait pas aussi impacté...
je confirme que ma livebox bien que connectée...
4.5 Type du protocole PPP
Donc en gros, ca serais le DHCPv4 qui serais en vrac si vos box fonctionne en PPP.
Perso j'ai tenté reboot de l'ONT, reboot plusieurs fois de la Livebox, impossible de la faire fonctionner. "wan_03_3001, contactez le 3900"
Je vais tenter de faire une conf PPPoE sur mon routeur pour voir si ca fix le pb.
-
bonjour,
ah ben tiens mon dhclient a récupérer une ip ce matin a 7h30
ça devait être un incident, mais pourtant la livebox avait récupérer une ip sur le vlan 832 cette nuit quand j'ai fait les tessts, j'ai bien fait attention de vérifier ce cas.
du coup j'en ai profité pour mettre l'option longue, au moins s'est fait.
Jerem
-
Bon, moi ça ne fonctionne ni avec l'USG, ni en direct avec la Livebox.
Il semble que ça soit un problème national Orange, le DHCPv4 semble HS.
Du coup je découvre internet en ipv6 only, et c'est pas la joie :(
-
et je viens de tester chez moi en PPPoE. Pas mieux.
Sans doute pour cela que ma box ne s'en sors pas.
Vive IPv6, wireguard et un serveur avec IPv6 dehors qui me permet de mettre internet a la maison (presque) comme si de rien n'était ...
-
C'est OK pour moi a l'instant.
DHCPv4 répond a nouveau, j'ai pu remettre mon backup de conf et tout fonctionne.
-
pour moi c'est définitivement out maintenant...
La livebox a switché en DHCPv4, elle a reçu une nouvelle IP d'ailleurs (ce qui n'était pas arrivé depuis que je suis client en 4 ans) mais le lien FTTH est marqué comme inactif et je n'ai plus de connection du tout... un reboot n'y change rien
-
Toujours KO pour moi aussi.
Je ne reçois toujours aucune réponse du DHCPv4... A suivre...
-
Idem, nouvelle IPv4 attribuée, mais pas de contact avec le DHCPv4...
-
Idem, nouvelle IPv4 attribuée, mais pas de contact avec le DHCPv4...
je comprends pas peux tu éclaircir ? si tu as eu une ip, tu as bien eu l'ip par le dhcp non ?
Jerem
-
Bon c'est finalement reparti chez moi vers 18h avec la même conf qu'avant.
Ouf, ils nous ont pas changé la méthode d'authent ! :P
-
je comprends pas peux tu éclaircir ? si tu as eu une ip, tu as bien eu l'ip par le dhcp non ?
Jerem
Ce que je veux dire, c'est que je n'ai pas de passerelle IPv4 (voir capture). Du coup, toujours pas moyen de joindre des sites en IPv4. De l'extérieure, on me joint bien même en IPv4.
-
De l'extérieure, on me joint bien même en IPv4.
Donc il y a bien une passerelle, sinon les paquets de retour ne pourraient pas être acheminés.
-
Correction, on me joint mais en IPv6 seulement aussi.
Avant la coupure, j'avais un WAN_DHCP4 qui était créé automatiquement. Il y a une option dans les paramètres WAN pour ça ?
-
J'ai rechargé une configuration sauvegardée il y a quelques jours et c'est bon, la passerelle est revenue et tout fonctionne !
-
Hello à tous,
Qu'est-ce que vous appelez 'option longue' svp ?
Y a t-il un autre script que celui de ZOC du mois d'Avril ?
merci
-
La version longue c'est celle que mon script (ainsi que celui de @kgersen) génère, et qui est techniquement identique à celle générée par la Livebox (à la différence près que la Livebox change le salt à chaque renouvellement DHCP).
La version courte, c'est en gros la version longue amputée du salt et du hash du mot de passe (il reste donc le login du client précédé de quelques octets de valeur constante). Elle fonctionne à priori mais ne correspond clairement pas au comportement de la box, preuve que pour l'instant Orange ne vérifie pas le mot de passe. Ca pourrait évidemment changer du jour au lendemain.
-
Merci Zoc pour ta réponse rapide :) la version longue correspond bien à ton dernier script d’avril, et c’est la dernière en date ? D’autre part, il me semblait avoir vu qque part qu’on pouvait dire à dhclient d’exécuter un script à chaque renew, et du coup avoir un salt dynamique, ça te dit qquechose ?
-
Pour ça il faut un patch qui de mémoire a été créé par @xavierg (il va falloir rechercher dans les premières pages de ce fil).
-
merci
-
L'option90 que vous appelez "longue", c'est bien celle avec le mot de passe et non que le fti ?
-
bonjour,
franchement il faut lire un peu, ça vient d'être répondu 3 postes au dessus...
Jerem
-
C'était pour être certain, il y a tellement d'infos éparpillés qu'on ne sait plus ou donner de la tête :D
-
Par ailleurs sur la Livebox 5, je n'ai pas réussi à sniffer les requêtes DHCP sur le port 4 ( port pour normalement mettre un ONT Huawei).
J'ai essayé de me mettre sur le VLAN 832 avec l'outil ProSet d'Intel pour les cartes réseaux, puis j'ai lancé un Wireshark pendant le démarrage de la LB5 sans la jarretière de l'ONT intégré branchée.
Même si aujourd'hui on connait les informations que demande les LB pour se connecter en DHCP, je me demande comment procéder sur la LB5.
Si vous avez une idée...
-
Pour ça il faut un patch qui de mémoire a été créé par @xavierg (il va falloir rechercher dans les premières pages de ce fil).
Tout est là : https://xavier.kindwolf.org/2018-orange-dhcp/ -- ça n'a pas changé depuis 2018, à part que de nos jours il faut mentionner buster et non plus stretch pour le dépôt Debian.
À noter que le patch a été proposé à l'ISC mais ils semblent objectivement s'en caresser les gonades avec du Nutella :)
S'il y a toujours des gens intéressés par cette approche, essayez de laisser un "thumbs up" sur https://gitlab.isc.org/isc-projects/dhcp/-/issues/136/ pour une éventuelle intégration upstream, et/ou sur la merge request associée : https://gitlab.isc.org/isc-projects/dhcp/-/merge_requests/69
-
Par ailleurs sur la Livebox 5,
J'ai utilisé les liveboxtools pour les options... mais je n'arrive pas à établir une connexion avec un TX-6610 ONT (O5 enregistré) et OPNsense...
Pour mon Livebox5:
DONNEES DHCP V4
dhcpstatus : Bound
IPRouters : xx.xx.xx.xx.xx
DHCPServer : xx.xx.xx.xx.xx
LeaseTime : 259200 = 72h 00min 00sec
LeaseTimeRemaining : 257156 = 71h 25min 56sec
DSCPMark : 48
PriorityMark : 6
CheckAuthentication : True
AuthenticationInformation: dhcpliveboxfr250
ResetOnPhysDownTimeout : 20
SentOption : 60,61,77,90
SentOption 60 : 736167656d #sagem
SentOption 61 : xxxxxxxxxxxxx #MACaddress
SentOption 77 : 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 #+FSVDSL_livebox.Internet.softathome.Livebox4
SentOption 90 : xxxxxxxxxx #long option-90
ReqOption : 1,3,6,15,28,51,58,59,90,119,120,125
DONNEES DHCP V6
dhcpstatus : Bound
DUID : xxxxxxx #DUID et MAC address
CheckAuthentication : True
AuthenticationInfo : dhcpliveboxfr250
ResetOnPhysDownTimeout : 20
SentOption : 11,15,16,17
SentOption 11 : xxxxxxx #option-90 long
SentOption 15 : 002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7834 #+FSVDSL_livebox.Internet.softathome.Livebox4
SentOption 16 : 0000040e0005736167656d #sagem
SentOption 17 : 000005580006000e495056365f524551554553544544 #IPV6_REQUESTED (in hex)
ReceivedOption : 25,11,2,1
mon problème est peut-être "Check Authentication = true" et le DHCP6 option-17 "IPV6_REQUESTED"??
[edit2]: Le TX-6610 a trouvé un WAN ipv4. Je testerai davantage le week-end en termes de bug de renouvellement du DHCP et j'extrairai les paramètres du TX-6610/opnsense pour référence future.
-
Suite à migration fibre pro de pfSense+ PPPoE 600/600 à LB5 2000/1000 je me suis procuré un ONT officiel HG8010Hv3 (offert par ma boutique Orange après quelques explications au 3901) afin de pouvoir repasser sur un vrais routeur.
L'up à 1Gbps c'est top mais pas les performances de la box en multithread (ça s'éfondre à cause des perfs CPU) exploter le 2Gb n'est pas ma priorité pour l'instant (testé avec succès sur 1 PC en sock5 dispatch sur 2 ports giga...).
Je peux donc passer facilement de la LB5 qui fonctionne; à l'ONT HG8010Hv3 qui arrive à l'étape "O5(Operation state)" + LED fibre OK
J'ai passé toute la journée à tester l'auth DHCP sur mon pfSense (qui a eu l'update officielle pfSense+ en replacement du firmware pfSense communautaire) pour obtenir les infos les plus up to date entre les différents thread de notre cher lafibre.info :
Send Options IPv4 :
dhcp-class-identifier "sagem", user-class "+FSVDSL_livebox.Internet.softathome.Livebox4", rfc3118-auth (chaine hex d'auth)
Request Options IPv4 :
subnet-mask, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, domain-search, routers, domain-name-servers, rfc3118-auth
Send Options IPv6 :
ia-pd 0, raw-option 6 00:0b:00:11:00:17:00:18, raw-option 15 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33, raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d, raw-option 11 (chaine hex d'auth)
Script avec lequel j'ai généré la chaine hex d'auth :
#!/bin/bash
login='fti/xxxxxxx'
pass='xxxxxxx'
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})
Et le log DHCP du pfSense+ avec debug DHCPv6 (mixé) :
[21.05.2-RELEASE][admin@firewall.serveurperso.com]/root: tail -f /var/log/dhcpd.log
Feb 7 05:09:07 firewall dhcp6c[96316]: Sending Solicit
Feb 7 05:09:07 firewall dhcp6c[96316]: freeing op data at 0x80066d048
Feb 7 05:09:07 firewall dhcp6c[96316]: freeing op data at 0x800a84330
Feb 7 05:09:07 firewall dhcp6c[96316]: freeing op data at 0x800a5e030
Feb 7 05:09:07 firewall dhcp6c[96316]: freeing op data at 0x800a67140
Feb 7 05:11:06 firewall dhcp6c[96316]: Sending Solicit
Feb 7 05:11:06 firewall dhcp6c[96316]: freeing op data at 0x80066d048
Feb 7 05:11:06 firewall dhcp6c[96316]: freeing op data at 0x800a842d0
Feb 7 05:11:06 firewall dhcp6c[96316]: freeing op data at 0x800a5e040
Feb 7 05:11:06 firewall dhcp6c[96316]: freeing op data at 0x800a67190
Feb 7 05:11:18 firewall dhclient[79622]: connection closed
Feb 7 05:11:18 firewall dhclient[79622]: exiting.
Feb 7 05:11:19 firewall dhcp6c[96316]: exiting
Feb 7 05:11:22 firewall dhclient[15186]: PREINIT
Feb 7 05:11:22 firewall dhclient[14871]: Registering receive interface: igb0
Feb 7 05:11:22 firewall dhclient[14871]: Interface igb0 attached to bpf for receiving
Feb 7 05:11:22 firewall dhclient[14871]: Registering sending interface: igb0
Feb 7 05:11:22 firewall dhclient[14871]: VLAN ID: 832, VLAN PCP: 6
Feb 7 05:11:22 firewall dhclient[14871]: Interface igb0 attached to bpf for sending
Feb 7 05:11:22 firewall dhclient[16247]: EXPIRE
Feb 7 05:11:22 firewall dhclient[16885]: Deleting old routes
Feb 7 05:11:22 firewall dhclient[17745]: PREINIT
Feb 7 05:11:22 firewall dhclient[14871]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 5
Feb 7 05:11:27 firewall dhclient[14871]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 6
Feb 7 05:11:33 firewall dhclient[14871]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 21
Feb 7 05:11:54 firewall dhclient[14871]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 7
Feb 7 05:12:01 firewall dhclient[14871]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 13
Feb 7 05:12:14 firewall dhclient[14871]: DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 9
Feb 7 05:12:24 firewall dhclient[14871]: No DHCPOFFERS received.
Feb 7 05:12:24 firewall dhclient[14871]: No working leases in persistent database - sleeping.
Feb 7 05:12:24 firewall dhclient[30184]: FAIL
Feb 7 05:12:27 firewall dhcp6c[30701]: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:1d:82:16:90:04:f0:21:16:8d:87
Feb 7 05:12:27 firewall dhcp6c[30701]: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Feb 7 05:12:27 firewall dhcp6c[30701]: failed initialize control message authentication
Feb 7 05:12:27 firewall dhcp6c[30701]: skip opening control port
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[interface] (9)
Feb 7 05:12:27 firewall dhcp6c[30701]: <5>[igb0] (4)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>begin of closure [{] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[send] (4)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[ia-pd] (5)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[0] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[send] (4)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[raw-option] (10)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[6] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[00:0b:00:11:00:17:00:18] (23)
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 3: Got raw option: 6 00:0b:00:11:00:17:00:18
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 3: Raw option 6 length 8 stored at 0x800a84060 with data at 0x80066d028
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[send] (4)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[raw-option] (10)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[15] (2)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33] (134)
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 4: Got raw option: 15 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 4: Raw option 15 length 45 stored at 0x800a840f0 with data at 0x800a84120
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[send] (4)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[raw-option] (10)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[16] (2)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[00:00:04:0e:00:05:73:61:67:65:6d] (32)
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 5: Got raw option: 16 00:00:04:0e:00:05:73:61:67:65:6d
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 5: Raw option 16 length 11 stored at 0x800a841e0 with data at 0x800a5e010
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[send] (4)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[raw-option] (10)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[11] (2)
Feb 7 05:12:27 firewall dhcp6c[30701]: <25>[00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:20:20:20:20:20:20:20:20:20:20:20:20:20:20:03:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:f6:b9:3d:d4:92:4f] (209)
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 6: Got raw option: 11 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:20:20:20:20:20:20:20:20:20:20:20:20:20:20:03:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:f6:b9:3d:d4:92:4f
Feb 7 05:12:27 firewall dhcp6c[30701]: /var/etc/dhcp6c_wan.conf 6: Raw option 11 length 70 stored at 0x800a84270 with data at 0x800a67050
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[script] (6)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>["/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh"] (46)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of closure [}] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[id-assoc] (8)
Feb 7 05:12:27 firewall dhcp6c[30701]: <13>[pd] (2)
Feb 7 05:12:27 firewall dhcp6c[30701]: <13>[0] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <13>begin of closure [{] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[prefix-interface] (16)
Feb 7 05:12:27 firewall dhcp6c[30701]: <5>[igb1] (4)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>begin of closure [{] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[sla-id] (6)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[0] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[sla-len] (7)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>[8] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of closure [}] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of closure [}] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: <3>end of sentence [;] (1)
Feb 7 05:12:27 firewall dhcp6c[30701]: called
Feb 7 05:12:27 firewall dhcp6c[30701]: freeing op data at 0x80066d028
Feb 7 05:12:27 firewall dhcp6c[30701]: freeing op data at 0x800a84120
Feb 7 05:12:27 firewall dhcp6c[30701]: freeing op data at 0x800a5e010
Feb 7 05:12:27 firewall dhcp6c[30701]: freeing op data at 0x800a67050
Feb 7 05:12:27 firewall dhcp6c[30701]: called
Feb 7 05:12:27 firewall dhcp6c[30885]: reset a timer on igb0, state=INIT, timeo=0, retrans=891
Feb 7 05:12:28 firewall dhcp6c[30885]: Sending Solicit
Feb 7 05:12:28 firewall dhcp6c[30885]: a new XID (43f490) is generated
Feb 7 05:12:28 firewall dhcp6c[30885]: set client ID (len 14)
Feb 7 05:12:28 firewall dhcp6c[30885]: set elapsed time (len 2)
Feb 7 05:12:28 firewall dhcp6c[30885]: set IA_PD
Feb 7 05:12:28 firewall dhcp6c[30885]: raw option 6 length 8 at 0x800a84360
Feb 7 05:12:28 firewall dhcp6c[30885]: set option request (len 8)
Feb 7 05:12:28 firewall dhcp6c[30885]: raw option 15 length 45 at 0x800a84330
Feb 7 05:12:28 firewall dhcp6c[30885]: set user class (len 45)
Feb 7 05:12:28 firewall dhcp6c[30885]: raw option 16 length 11 at 0x800a842d0
Feb 7 05:12:28 firewall dhcp6c[30885]: set vendor class (len 11)
Feb 7 05:12:28 firewall dhcp6c[30885]: raw option 11 length 70 at 0x800a842a0
Feb 7 05:12:28 firewall dhcp6c[30885]: set authentication (len 70)
Feb 7 05:12:28 firewall dhcp6c[30885]: send solicit to ff02::1:2%igb0
Feb 7 05:12:28 firewall dhcp6c[30885]: freeing op data at 0x80066d048
Feb 7 05:12:28 firewall dhcp6c[30885]: freeing op data at 0x800a84300
Feb 7 05:12:28 firewall dhcp6c[30885]: freeing op data at 0x800a5e040
Feb 7 05:12:28 firewall dhcp6c[30885]: freeing op data at 0x800a67190
Feb 7 05:12:28 firewall dhcp6c[30885]: reset a timer on igb0, state=SOLICIT, timeo=0, retrans=1091
Feb 7 05:12:29 firewall dhcp6c[30885]: Sending Solicit
Feb 7 05:12:29 firewall dhcp6c[30885]: set client ID (len 14)
Feb 7 05:12:29 firewall dhcp6c[30885]: set elapsed time (len 2)
Feb 7 05:12:29 firewall dhcp6c[30885]: set IA_PD
Feb 7 05:12:29 firewall dhcp6c[30885]: raw option 6 length 8 at 0x800a842a0
Feb 7 05:12:29 firewall dhcp6c[30885]: set option request (len 8)
Feb 7 05:12:29 firewall dhcp6c[30885]: raw option 15 length 45 at 0x800a842d0
Feb 7 05:12:29 firewall dhcp6c[30885]: set user class (len 45)
Feb 7 05:12:29 firewall dhcp6c[30885]: raw option 16 length 11 at 0x800a84300
Feb 7 05:12:29 firewall dhcp6c[30885]: set vendor class (len 11)
Feb 7 05:12:29 firewall dhcp6c[30885]: raw option 11 length 70 at 0x800a84360
Feb 7 05:12:29 firewall dhcp6c[30885]: set authentication (len 70)
Feb 7 05:12:29 firewall dhcp6c[30885]: send solicit to ff02::1:2%igb0
Feb 7 05:12:29 firewall dhcp6c[30885]: freeing op data at 0x80066d048
Feb 7 05:12:29 firewall dhcp6c[30885]: freeing op data at 0x800a84330
Feb 7 05:12:29 firewall dhcp6c[30885]: freeing op data at 0x800a5e030
Feb 7 05:12:29 firewall dhcp6c[30885]: freeing op data at 0x800a67140
Feb 7 05:12:29 firewall dhcp6c[30885]: reset a timer on igb0, state=SOLICIT, timeo=1, retrans=2083
Feb 7 05:12:30 firewall dhcpd[52624]: Internet Systems Consortium DHCP Server 4.4.2-P1
Feb 7 05:12:30 firewall dhcpd[52624]: Copyright 2004-2021 Internet Systems Consortium.
Feb 7 05:12:30 firewall dhcpd[52624]: All rights reserved.
Feb 7 05:12:30 firewall dhcpd[52624]: For info, please visit https://www.isc.org/software/dhcp/
Feb 7 05:12:30 firewall dhcpd[52624]: Config file: /etc/dhcpd.conf
Feb 7 05:12:30 firewall dhcpd[52624]: Database file: /var/db/dhcpd.leases
Feb 7 05:12:30 firewall dhcpd[52624]: PID file: /var/run/dhcpd.pid
Feb 7 05:12:30 firewall dhcpd[52624]: Internet Systems Consortium DHCP Server 4.4.2-P1
Feb 7 05:12:30 firewall dhcpd[52624]: Copyright 2004-2021 Internet Systems Consortium.
Feb 7 05:12:30 firewall dhcpd[52624]: All rights reserved.
Feb 7 05:12:30 firewall dhcpd[52624]: For info, please visit https://www.isc.org/software/dhcp/
Feb 7 05:12:30 firewall dhcpd[52624]: Wrote 0 class decls to leases file.
Feb 7 05:12:30 firewall dhcpd[52624]: Wrote 3 leases to leases file.
Feb 7 05:12:30 firewall dhcpd[52624]: Listening on BPF/igb1/00:08:a2:0b:bd:b3/192.168.0.0/24
Feb 7 05:12:30 firewall dhcpd[52624]: Sending on BPF/igb1/00:08:a2:0b:bd:b3/192.168.0.0/24
Feb 7 05:12:30 firewall dhcpd[52624]: Sending on Socket/fallback/fallback-net
Feb 7 05:12:30 firewall dhcpd[52624]: Server starting service.
Feb 7 05:12:31 firewall dhcp6c[30885]: Sending Solicit
Feb 7 05:12:31 firewall dhcp6c[30885]: set client ID (len 14)
Feb 7 05:12:31 firewall dhcp6c[30885]: set elapsed time (len 2)
Feb 7 05:12:31 firewall dhcp6c[30885]: set IA_PD
Feb 7 05:12:31 firewall dhcp6c[30885]: raw option 6 length 8 at 0x800a84360
Feb 7 05:12:31 firewall dhcp6c[30885]: set option request (len 8)
Feb 7 05:12:31 firewall dhcp6c[30885]: raw option 15 length 45 at 0x800a84300
Feb 7 05:12:31 firewall dhcp6c[30885]: set user class (len 45)
Feb 7 05:12:31 firewall dhcp6c[30885]: raw option 16 length 11 at 0x800a84330
Feb 7 05:12:31 firewall dhcp6c[30885]: set vendor class (len 11)
Feb 7 05:12:31 firewall dhcp6c[30885]: raw option 11 length 70 at 0x800a842a0
Feb 7 05:12:31 firewall dhcp6c[30885]: set authentication (len 70)
Feb 7 05:12:31 firewall dhcp6c[30885]: send solicit to ff02::1:2%igb0
Feb 7 05:12:31 firewall dhcp6c[30885]: freeing op data at 0x80066d048
Feb 7 05:12:31 firewall dhcp6c[30885]: freeing op data at 0x800a842d0
Feb 7 05:12:31 firewall dhcp6c[30885]: freeing op data at 0x800a5e040
Feb 7 05:12:31 firewall dhcp6c[30885]: freeing op data at 0x800a67190
Feb 7 05:12:31 firewall dhcp6c[30885]: reset a timer on igb0, state=SOLICIT, timeo=2, retrans=3982
Feb 7 05:12:35 firewall dhcp6c[30885]: Sending Solicit
Je suis dispo pour des essais avec la fibre pro avec des contraintes de ne pas couper les utilisateurs de mon serveurperso:D
Pascal
-
CoS ?
-
Hello, alors en voyant ton message ce matin j'ai rebranché l'ONT et pfSense, j'ai actuellement mis les 2 binaires patchés qu'on trouve ici https://wiki.virtit.fr/doku.php/kb:linux:pfsense:remplacer_sa_box_orange_par_un_pfsense
Sans le /sbin/dhclient/dhclient patché sur mon pfSense+ j'ai des erreurs de parse du fichier de conf
Le /usr/local/sbin/dhcp6c patché je crois justement que c'est pour set ce CoS uniquement pour DHCP grâce aux options modifiers (vlan-pcp 6), mais je peux facilement swapper de l'un a l'autre je garde les originaux en .old comme ceci
[21.05.2-RELEASE][admin@firewall.serveurperso.com]/sbin: ls -l dhclient*
-r-xr-xr-x 1 root wheel 109320 Feb 7 04:30 dhclient
-r-xr-xr-x 1 root wheel 9890 Oct 22 2021 dhclient-script
-r-xr-xr-x 1 root wheel 99592 Oct 22 2021 dhclient.old
[21.05.2-RELEASE][admin@firewall.serveurperso.com]/sbin: cd /usr/local/sbin/
[21.05.2-RELEASE][admin@firewall.serveurperso.com]/usr/local/sbin: ls -l dhcp6c*
-r-xr-xr-x 1 root wheel 152840 Feb 7 04:09 dhcp6c
-r-xr-xr-x 1 root wheel 148296 Jul 27 2021 dhcp6c.old
-r-xr-xr-x 1 root wheel 17720 Jul 27 2021 dhcp6ctl
J'ai l'option modifier :
send-interface "igb0", vlan-id 832, vlan-pcp 6
J'ai fait un VLAN 832 sur l'interface WAN avec un VLAN Priority à 0 (paramètre vide par défaut)
Je n'ai pas sélectionné cette interface "virtuelle" au niveau de l'interface WAN par défaut car l'option modifier fait le job j'ai mis les screens
(vu sur la doc pfSense vlan-pcp 6 ne fonctionne que si net.link.vlan.mtag_pcp = 1 ce qui est le cas par défaut)
[21.05.2-RELEASE][admin@firewall.serveurperso.com]/usr/local/sbin: sysctl net.link.vlan.mtag_pcp
net.link.vlan.mtag_pcp: 1
Aussi j'ai du remplacer "option-90" par "rfc3118-auth" aussi bien dans Send option que dans Request option de DHCP sinon erreur parse
Voila
-
Voici les fichiers de conf DHCP générés car entre temps j'avais bouffé les options DHCPv6 15 16 11:(
Toujours pas d'IP reçue sur mon interface wan:(
[21.05.2-RELEASE][admin@firewall.serveurperso.com]/root: cat /var/etc/dhclient_wan.conf
interface "igb0" {
supersede interface-mtu 0;
# DHCP Protocol Timing Values
# DHCP Protocol Options
send dhcp-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox4";
send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1A:09:xx:00:xx:58:01:03:41:01:xx:xx:74:69:xx:6b:32:xx:67:72:79:66:3C:xx:xx:xx:xx:35:35:61:36:63:65:39:xx:xx:xx:xx:xx:39:03:13:30:25:xx:xx:xx:xx:5d:0b:92:2a:cc:xx:xxx:xx:xx:xx:xx;
request subnet-mask, broadcast-address, dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, domain-search, routers, domain-name-servers, rfc3118-auth;
send-interface "igb0";
vlan-id 832;
vlan-pcp 6;
script "/usr/local/sbin/pfSense-dhclient-script";
}
[21.05.2-RELEASE][admin@firewall.serveurperso.com]/root: cat /var/etc/dhcp6c_wan.conf
interface igb0 {
send ia-pd 0;
send raw-option 6 00:0b:00:11:00:17:00:18;
send raw-option 15 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33;
send raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d;
send raw-option 11 00:00:00:00:00:00:00:00:00:00:00:1A:09:xx:00:xx:58:01:03:41:01:xx:xx:74:69:xx:6b:32:xx:67:72:79:66:3C:xx:xx:xx:xx:35:35:61:36:63:65:39:xx:xx:xx:xx:xx:39:03:13:30:25:xx:xx:xx:xx:5d:0b:92:2a:cc:xx:xxx:xx:xx:xx:xx;
script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh";
};
id-assoc pd 0 {
prefix-interface igb1 {
sla-id 0;
sla-len 8;
};
};
-
Bonjour @Serveurperso,
Peut-être inutile, je ne connais pas PfSense, mais je ne vois nulle part "send dhcp-client-identifier 01:XX:XX:XX:XX:XX:XX;" avec XX:XX:XX:XX:XX:XX adresse MAC de la LiveBox et ne pas oublier le 01 devant l'adresse MAC
-
Bonjour @Serveurperso,
Peut-être inutile, je ne connais pas PfSense, mais je ne vois nulle part "send dhcp-client-identifier 01:XX:XX:XX:XX:XX:XX;" avec XX:XX:XX:XX:XX:XX adresse MAC de la LiveBox et ne pas oublier le 01 devant l'adresse MAC
Merci Lucy-Han c'est noté pour le prochain essai:) J'avais fait un essai sans succès avec l'adresse mac de livebox 5 dans le champ de l'IHM dédié sur le pfSense+ et donc sûrement que le premier octet 01 est aussi absent de l'option dhcp-client-identifier du fichier de conf généré, l'option entière sera à vérifier dans le fichier.
Mais a ce qu'il me semble voir partout le dhcp-client-identifier avec le 01 c'est sur une autre interface dédiée pour les flux VOD (et seule la co IPv4 avec mon IP fixe m'intéresse, et éventuellement l'IPv6 quand l'IPv4 sera fonctionnel)
-
@Serveurperso : tu as raison, je viens de faire un reboot sans l'option send dhcp-client-identifier et j'obtiens IPV4/IPV6. Une ligne de moins dans les fichiers de configuration !
-
Du coup je sais plus quoi tester, mis à part faire une box avec une de mes PI et une interface ethernet USB juste pour tester sous linux avec une conf moins spécifique à un firmware de routeur, car devoir utiliser des clients dhcp patchés sous pfsense+ c'est pas l'extase
-
Ceci dit, la Livebox, elle, elle envoie son adresse mac dans dhcp-client-identifier. Sur le VLAN 832, oui (avant qu'on me pose la question).
Je pense que là maintenant, le plus simple, c'est de brancher un PC sur le port WAN du routeur et de voir avec Wireshark si tout est bien correct dans les requêtes DHCP envoyées (et notamment la prio).
Et sinon, la LB5 elle arrive à se connecter avec l'ONT externe connecté à son port WAN cuivre ? Parce que perso les 2 ONT enregistrés pour le même client je suis un peu sceptique.
-
Ceci dit, la Livebox, elle, elle envoie son adresse mac dans dhcp-client-identifier. Sur le VLAN 832, oui (avant qu'on me pose la question).
Je pense que là maintenant, le plus simple, c'est de brancher un PC sur le port WAN du routeur et de voir avec Wireshark si tout est bien correct dans les requêtes DHCP envoyées (et notamment la prio).
Et sinon, la LB5 elle arrive à se connecter avec l'ONT externe connecté à son port WAN cuivre ? Parce que perso les 2 ONT enregistrés pour le même client je suis un peu sceptique.
Donc je vais tester l'ajout de dhcp-client-identifier avec la mac, et le 01 aussi de ce côté WAN ? Lors de la prochaine coupure possible un matin.
Si l'ONT n'était pas accepté la LED fibre serait elle rouge ? ou l'état en dessous de 05(operation state) ? Car je dispose d'un autre ONT officiel orange, un ancien Alcatel-lucent, un gros blanc. lol. et lui était passé en rouge définitif côté fibre lors du test juste après avoir branché ma 1ere livebox 5.
+ le SMS bienvenue sur le réseau Orange, SMS qui se produit à chaques changement de Livebox 5, vu que c'est ma 3ème livebox 5...
La première avais le bouton wifi malformé (et inutilisable, même si je disable le wifi de la box), la seconde j'ai niqué le firmware je sais pas comment avec juste des poweroff brutaux et justement en voulant tester avec l'ONT externe officiel donné par Orange, et ce avec un tech du 3901 qui n'a pas pu m'aider autrement que d'aller récupérer la 3ème Livebox 5...
La Livebox 5 semble ne pas fonctionner avec un ONT externe sinon je me serais empressé de sniffer le trafic intermédiaire avec mon switch en port mirroring.
Du coup faudrait que je wireshark ce qui sort de mon pfSense.
-
La Livebox 5 semble ne pas fonctionner avec un ONT externe
Si si....
-
Si si....
Quelqu'un à déjà essayé avec la fibre pro et le firmware pro de la box ? Car dans ce cas je pourrais tester et si NOK bassiner le 3901
Car le symptome de ma 2eme freebox 5 HS c'était ONT interne HS, juste après avoir testé l'ONT externe avec le 3901 ! Sauf si une extinction l'a tuée pendant l'essai....
-
https://lafibre.info/remplacer-livebox/mise-en-route-leox-lxt-010h-d/
Je crois que @nscheffer a au moins une offre pro.
-
https://lafibre.info/remplacer-livebox/mise-en-route-leox-lxt-010h-d/
Je crois que @nscheffer a au moins une offre pro.
Je confirme j'ai une Fibre Orange Open UP et une deuxième Fibre Orange Pro Open. Je précise que sur une offre Orange Pro avec une Livebox 5 qu'elle est identique sur le matériel avec une Livebox 5 de chez Orange Grand Public, seul le firmware est different.
Les deux sont avec une Livebox 5 sur lesquelles j'ai mis sur chaque un ONT/ONU LEOX qui fonctionne à merveille.
L'étape suivante est de virer les deux Livebox 5 pour connecter les deux LEOX directement sur mon FortiGate.
J'ai déjà fait la manip dans le passé avec du Mikrotik, Ubiquiti et du pfSense, OpenWRT, etc... je peux confirmer que la config et les options à avoir sont identique entre l'offre Pro et Grand Public.
A l'époque j'ai fait les manips suivantes :
- sur chaque Livebox 5 sur leur interface je récupère les infos de l'ONT (Serial, Hardware Version), je me fais aussi des screenshots pour avoir tout
- j'utilise ensuite l'outil https://www.liveboxinfos.ga sous Windows pour récupérer les options DHCP que la Livebox 5 envoi (options 60, 61, 77 et 90 et v4 et options 11,15,16 et 17 en v6) et je les utilise pour la suite, pas besoin de conversion, etc...
- configuration du ONT/ONU et test sur le port 4 de la Livebox
- test final sur le boitier qui remplace la livebox avec les paramètres ci-dessus
C'est tout !
Nicolas
-
-
Super good news ! Du coup je devrais pouvoir re-tenter sans risquer d'exploser le firmware version "pro"... car si ça crash de la même façon que sur ma seconde LB5 testée avec l'ONT orange et le 3901, j'suis dans la m... (télétravail & serveur coupés), je m'en suis taper des allers retours à la boutique Orange !
Sur ton ONT LEOX t'as du spoof le numéro de série de la LB5 ou pas ?
Oui j'ai aussi noté dans un fichier texte toutes les infos de la LB5, mais je vais voir les outils https://www.liveboxinfos.ga ça a l'air pratique
Aussi la grande question c'est de savoir si un ONT hg8010hv3 officiel Orange arrivé à l'étape O5 et à LED fibre verte est bien fonctionnel ou si une couche applicative me bloque encore côté infra orange...
-
Super good news ! Du coup je devrais pouvoir re-tenter sans risquer d'exploser le firmware version "pro"... car si ça crash de la même façon que sur ma seconde LB5 testée avec l'ONT orange et le 3901, j'suis dans la m... (télétravail & serveur coupés), je m'en suis taper des allers retours à la boutique Orange !
Sur ton ONT LEOX t'as du spoof le numéro de série de la LB5 ou pas ?
Oui j'ai aussi noté dans un fichier texte toutes les infos de la LB5, mais je vais voir les outils https://www.liveboxinfos.ga ça a l'air pratique
Aussi la grande question c'est de savoir si un ONT hg8010hv3 officiel Orange arrivé à l'étape O5 et à LED fibre verte est bien fonctionnel ou si une couche applicative me bloque encore côté infra orange...
Pour le LEOX que j'ai depuis peu j'ai été soufflé de la faciliter à le configurer et surtout ca a marché du premier coup !
Je remets mon post sur la manip :
Juste faire un telnet sur le boitier :
ip 192.168.1.1
login leox
password leolabs_7
puis un change le GPON Serial qui est celui de la Livebox 5 on le trouve dans la partie "Information Système" et le Vendor ID sont les 4 premiers chiffres :
flash set GPON_SN SMBSXXXXXXXX
flash set PON_VENDOR_ID SMBS
Par contre les autres ONT, j'ai testé du Nokia, Alcatel, etc... c'est quand même galère, il faut en général passer par un Carlitox et tu as quand même plusieurs paramètres à renseigner...
Le LEOX c'est quasiment du plug and play.
Test intermédiaire important : mets ton LEOX ou autre ONT sur le port 4 de la Livebox 5 avant de virer la livebox pour être sur que ton ONT monte bien et fonctionne.
-
Suite au tests de ce matin je crois que j'ai compris un truc :
Mon ONT officiel récupéré en boutique Orange, le HG8010Hv3, dans son onglet "Service Provisioning Status" :
ONT Registration Status: Successfully registered the ONT with the OLT.
OLT Service Configuration Status: The OLT is applying configurations. Please wait.
Please wait forever:(
J'ai testé un long moment sur le port 4 de la Livebox sans succès... Pour elle pas de fibre... Par contre au comportement du firmware et des la leds ethernet sur l'ONT ya des essais...
Vu qu'on peut pas changer le numéro de série du HG8010Hv3 j'ai 2 soluces : tanner le 3901 pour me faire enregistrer le numéro de série sur mon profil, ou acheter un ONT LEOX qui le permet
l'avantage du LEOX c'est que j'ai double possibilité de fallback (Livebox 5 seule ou Livebox 5 + ONT ethernet) en dépannage, sans re appeler le 3901...
-
Ou acheter le LEOX ? je ne trouve que ça rapidement sur google http://xbest.pl/index.php?p3395,ont-gpon-lxt-010g-d-leox-1xge-1xgpon-sc-apc
-
Ou acheter le LEOX ? je ne trouve que ça rapidement sur google http://xbest.pl/index.php?p3395,ont-gpon-lxt-010g-d-leox-1xge-1xgpon-sc-apc
Pour le moment c'est le seul distributeur qui est en Pologne !
Le paiement uniquement par virement.
-
Ben avec cette soluce j'ai pas mon réseau au top avant noel:( lol je vais donc tanner le 3901...
le seul truc qui peux fonctionner c'est d'être hyper gentil avec eux et de leur dire que je mets systématiquement la note maxi au mail de satisfaction pour mes essais...
J'ai envie de rester sur l'IHM 192.168.4.254 pour voir le "OLT Service Configuration Status: The OLT is applying configurations. Please wait." changer en direct et normalement cette IP devrait même disparaître une fois la connexion avec l'OLT vraiment établie comme le rapporte pas mal de gens ici.
-
Bingo ! Suffit d'être cool au téléphone, en moins de 5 minutes de 3901 me voila connecté avec mon ONT externe en 1Gbps symétrique (950 950 sur speedtest !) sur le port 4 de la livebox 5 ! J'ai même vu l'IHM disparaître immédiatement après que l'ONT ai monté.
L'appel à duré 1H juste pour le plaisir d'échanger avec la technicienne que j'ai eu... Sur des anecdotes technique de gens qui ragent au téléphone et de geeks qui veulent passer sur routeur perso, comme quoi ils ne sont absolument pas contre ! Du moins en pro, je n'ai pas d’expériences avec le 3900 fibre pour particuliers...
Elle m'a garanti que faire enregistrer le numéro de série de n'importe quel ONT perso chez Orange c'est facile et rapide, et n'importe quel téléconseiller le fera, et ce même plusieurs fois pour différents ONT, elle était prête à me rappeler dans 1H après mes essais au cas ou je devais fallback sur l'ONT interne -> Ce sera email d'enquête avec note maxi pour moi.
Maintenant je peux enfin tester mon DHCP pfSense+ avec fallback possible sur la LB5 en mode ONT externe impec:D
Paf j'ai reçu mon IPv4 fixe sur le pfSense enfin:D peaufinage de la config...
-
L'appel à duré 1H juste pour le plaisir d'échanger avec la technicienne que j'ai eu... Sur des anecdotes technique de gens qui ragent au téléphone et de geeks qui veulent passer sur routeur perso, comme quoi ils ne sont absolument pas contre !
punaise ! une heure de plus et tu pouvais l'inviter pour un repas aux chandelles dans un burger king !!! ;D ;D
-
L'appel à duré 1H juste pour le plaisir d'échanger avec la technicienne que j'ai eu...
Sauf qu'il n'y a pas 1 heure entre les deux messages, et si on compte le temps d'attente, la conversation réelle doit être bien plus courte
( lol je vais donc tanner le 3901...
-
PTDR@cetipabo ckler !!!! EDIT : @Lucien oui en fait j'ai pas chronométré en plus j'étais dans l'espace temps ou ma co était coupée:)
J'ai reset le pfSense+ 21.05.2-RELEASE usine pour repartir sur du neuf et le publier ici :
-> Les deux binaires des clients DHCP v4 et 6 sont restés patchés, normal, j'ai même testé les deux binaires stock du firmware indépendamment pour confirmer la nécessité du patchage sur le pfSense+ :
- Le binaire du client DHCP v4 doit être patché pour ne pas avoir à définir la priorité au niveau du VLAN 832 (via l'IHM) qui serait valable pour tout le trafic (et donc ralentissement si j'ai bien vu à droite à gauche) mais au niveau de l'option modifier du client DHCP V4 avec "vlan-pcp 6" sinon parse error du fichier de conf généré par l'IHM.
- Le binaire du client DHCP v6 doit être patché aussi pour obtenir une gateway IPv6 sinon parse error du fichier de conf généré par l'IHM.
Ce qu'ils oublient de dire (ou alors que j'avais pas compris et ce qui m'a fait perdre un peu de temps) sur https://wiki.virtit.fr/doku.php/kb:linux:pfsense:remplacer_sa_box_orange_par_un_pfsense c'est qu'il faut bien attacher ce VLAN 832 à tout "WAN" dans le pfSense, et que les option modifiers qu'on trouve un peu partout *send-interface "igb0"* et *vlan-id 832* ne servent à rien et ne fonctionnent pas que ce soit avec ou sans attacher ce VLAN 832 à WAN par l'IHM. J'ai testé toutes les combinaisons et même un *send-interface "igb0.832"*
Tout le trafic passe donc par le VLAN 832 mais la priorité CoS 6 est seulement définie pour le client DHCPv4 grace au fameux option-modifier "vlan-pcp 6"
J'ai mes 1Gbps symétrique avec ce pfSense+ boitier alu officiel qui n'est même plus en vente car sa MoBo chauffe grave et grille si on ne lui met pas un petit ventilo sur le boitier (j'en ai grillé 1 et un ami grillé 1 aussi et la je tourne avec la dernière révision hard de la MoBo jamais vendue par pfSense pour ce modèle 2 ports)
Et le traditionnel speedtest pour finir. Mon beau 1Gbps symétrique impec sans aucune gigue sur ma robotique temps réel même avec des tonnes de threads contrairement à avec la LB5 en attendant de pousser le vice avec du 10GB
-
Pour le LEOX que j'ai depuis peu j'ai été soufflé de la faciliter à le configurer et surtout ca a marché du premier coup !
Je remets mon post sur la manip :
Juste faire un telnet sur le boitier :
ip 192.168.1.1
login leox
password leolabs_7
puis un change le GPON Serial qui est celui de la Livebox 5 on le trouve dans la partie "Information Système" et le Vendor ID sont les 4 premiers chiffres :
flash set GPON_SN SMBSXXXXXXXX
flash set PON_VENDOR_ID SMBS
Par contre les autres ONT, j'ai testé du Nokia, Alcatel, etc... c'est quand même galère, il faut en général passer par un Carlitox et tu as quand même plusieurs paramètres à renseigner...
Le LEOX c'est quasiment du plug and play.
Test intermédiaire important : mets ton LEOX ou autre ONT sur le port 4 de la Livebox 5 avant de virer la livebox pour être sur que ton ONT monte bien et fonctionne.
Je viens de tester la procédure avec le Leox fraîchement arrivé et ça ne fonctionne pas chez moi. J'ai bien mis l'ARLT sur le Vendor ID et le serial ARLTXXXXXXXXX ensuite branché sur le port 4 de la Livebox 5 sans succès. Après c'est curieux que pour se connecter sur le Leox c'est la même IP que la LB 5: 192.168.1.1. J'ai aussi changé le plan d'adressage de la LB 5 avec 192.168.0.1 sans de meilleurs résultats.
Sur la Leox j'ai bien les voyants PON qui devient vert fixe suite au branchement de la fibre (pendant la sync ca clignote vert) et le LAN clignote quand c'est branché sur la LB 5 et même après un redémarrage de cette dernière, rien ne se passe !
-
Je viens de tester la procédure avec le Leox fraîchement arrivé et ça ne fonctionne pas chez moi. J'ai bien mis l'ARLT sur le Vendor ID et le serial ARLTXXXXXXXXX ensuite branché sur le port 4 de la Livebox 5 sans succès. Après c'est curieux que pour se connecter sur le Leox c'est la même IP que la LB 5: 192.168.1.1. J'ai aussi changé le plan d'adressage de la LB 5 avec 192.168.0.1 sans de meilleurs résultats.
Sur la Leox j'ai bien les voyants PON qui devient vert fixe suite au branchement de la fibre (pendant la sync ca clignote vert) et le LAN clignote quand c'est branché sur la LB 5 et même après un redémarrage de cette dernière, rien ne se passe !
Ah zut !
Moi je suis dans le 78 avec un OLT Alcatel et une Livebox 5 SMBSXXXXXXXX, ce qui est sur tu as une Livebox en ARLTXXXXXXXXX, sais tu quel est ton OLT ?
Si tu fais des captures c'est facile de savoir au travers de la MAC de l'OLT.
Que donne les voyants de la Livebox ?
Tu as bien éteins au moins 1min la Livebox avant de faire le test ?
-
Merci pour ton retour très rapide Nicolas. Je ne l'ai pas fait pendant 1 min, je vais le refaire ce midi merci. Pour l'IP, tu peux m'en dire un peu plus comment le Port 4 de la LB communique avec le LEOX. Ai-je besoin de me soucier des IPs sur chacun des deux ou est-ce à partir de LB que le DHCP spécifique Orange se fait donc peu importe les IPs sur la LB et sur le Leox ?
Pour les captures, je ne peux pas utiliser le Leox en direct pour qu'il me donne le traffic ? Si oui, tu sais comment ? Si non, je chercherais et je le ferais si le test d'arrêter la LB au moins 1 min ne donne aucun résultat.
Merci encore pour ton aide, c'est top
-
Merci pour ton retour très rapide Nicolas. Je ne l'ai pas fait pendant 1 min, je vais le refaire ce midi merci. Pour l'IP, tu peux m'en dire un peu plus comment le Port 4 de la LB communique avec le LEOX. Ai-je besoin de me soucier des IPs sur chacun des deux ou est-ce à partir de LB que le DHCP spécifique Orange se fait donc peu importe les IPs sur la LB et sur le Leox ?
Pour les captures, je ne peux pas utiliser le Leox en direct pour qu'il me donne le traffic ? Si oui, tu sais comment ? Si non, je chercherais et je le ferais si le test d'arrêter la LB au moins 1 min ne donne aucun résultat.
Merci encore pour ton aide, c'est top
Quand j'ai reçu le LEOX j'ai fait les deux changements, on-off la Livebox 5 pendant plus de 1Min et hop ca a marché du premier coup pour mes deux Livebox 5 (Orange et Orange Pro).
J'ai pas mal discuté avec Marcin (celui qui fabrique le LEOX en Pologne) et je lui ai fait part de mes retours et feedbacks. Il m'a aussi dit que la plupart des ONT du marché sont sur un SDK Luna 1.9 (Kernel 2.6.x) alors que le LEOX est sur le SDK Luna 3.3 (Kernel 3.18.x) mais il a besoin de 16Mb de Flash.
Tu as besoin de rien faire d'autre sur le LEOX il est vraiment Plugn and Play...avec toute la puissance du SDK Luna pour analyser, monitorer et configurer ce que tu veux mais j'en ai pas besoin dans mon cas.
Pour la com entre la Livebox et le LOEX pour moi le LEOX est transparent pour la Livebox. Une fois que le LEOX est connecté sur l'OLT, la Livebox peut faire sa requête DHCP avec la CoS 6 sur le Vlan 832 en traversant le LEOX. Le LEOX ne fait aucune routage, c'est que du niveau 2...
Ce que tu peux faire est de mettre un switch entre le LEOX et la Livebox 5 puis faire une capture Wireshark, l'analyse donnera vite la cause du problème.
-
Bon, ça ne marche pas. la lumière blanche de la LB5 sur Internet clignote et sur le Leox c'est les 2 premières qui sont fixes vertes.
Reste plus qu'aller faire une analyse des trames ce we car le lieu où est la fibre n'est pas très accessible.
Merci pour tes explications, j'y vois plus clair.
-
Bonjour,
Après pas mal de lecture, je me lance dans un PFSense avec le petit tric du 2Gbps. Pour le moment tout semble ok niveau hardware, je vais donc passer à la conf du PFSense.
J'ai donc une question sur la partie chaine d'authentification FTI en hexa est-ce que le fti/id + pwd suffit ou est-ce qu'il faut également les deux autres chaines issus d'un dump de l'interface WAN?
En fait en lisant les postes je n'arrive pas à savoir si les deux parties RND (salt et byte) sont obligatoire ou pas.
D'avance merci :-)
-
Bonjour,
Après pas mal de lecture, je me lance dans un PFSense avec le petit tric du 2Gbps. Pour le moment tout semble ok niveau hardware, je vais donc passer à la conf du PFSense.
J'ai donc une question sur la partie chaine d'authentification FTI en hexa est-ce que le fti/id + pwd suffit ou est-ce qu'il faut également les deux autres chaines issus d'un dump de l'interface WAN?
En fait en lisant les postes je n'arrive pas à savoir si les deux parties RND (salt et byte) sont obligatoire ou pas.
D'avance merci :-)
je t'ai répondu dans l'autre post mais en fait l'outil de récupération des données aurait plus sa place ici. Donc je le joins à ma réponse.
Pour ce qui est du fonctionnement, il suffit d'avoir sa livebox branchée, puis de lancer l'outil. On indique le pass d'accès à l'interface web de la livebox, on clique "connexion", et il ne reste plus qu'à copier les valeurs indiquées. Ce sont celles que la livebox envoie pour faire l'authentification. Donc rien à modifier ou calculer.
(https://i.imgur.com/GOdKQs5.png)
EDIT:
Fichier remplacé par un autre qui fonctionne sous Linux avec Wine.
-
Top,
Merci encore, cet outil est vraiment super pratique!
-
j'ai remplacé le fichier par une version qui marche sur Windows et Linux sous Wine (validée par @petrus)
j'ai désactivé le ping de test qui permet de vérifier la présence d'un équipement sur l'ip qui est indiqué dans l'interface. Apparement sous linux le ping n'est pas interpreté correctement ce qui empeche l'appli de fonctionner.
-
j'ai remplacé le fichier par une version qui marche sur Windows et Linux sous Wine (validée par @petrus)
j'ai désactivé le ping de test qui permet de vérifier la présence d'un équipement sur l'ip qui est indiqué dans l'interface. Apparement sous linux le ping n'est pas interpreté correctement ce qui empeche l'appli de fonctionner.
Hello
J'ai testé la nouvelle version avec wine, ça fonctionne !
Et pourquoi ça ne fonctionnait pas avec le ping, la réponse est ici https://bbs.archlinux.org/viewtopic.php?id=250393
Et donc sauf à lancer en root peut de chance que ça fonctionne.
-
Hello
J'ai testé la nouvelle version avec wine, ça fonctionne !
Et pourquoi ça ne fonctionnait pas avec le ping, la réponse est ici https://bbs.archlinux.org/viewtopic.php?id=250393
Et donc sauf à lancer en root peut de chance que ça fonctionne.
bien vu ! ;)
-
Et donc sauf à lancer en root peut de chance que ça fonctionne.
et sinon plutôt que de sortir la grosse artillerie et lancer en root des milliers de ligne de code, on peut faire les choses proprement :)
sudo setcap cap_net_raw+epi /usr/bin/wine-preloader
-
PTDR@cetipabo ckler !!!! EDIT : @Lucien oui en fait j'ai pas chronométré en plus j'étais dans l'espace temps ou ma co était coupée:)
J'ai reset le pfSense+ 21.05.2-RELEASE usine pour repartir sur du neuf et le publier ici :
-> Les deux binaires des clients DHCP v4 et 6 sont restés patchés, normal, j'ai même testé les deux binaires stock du firmware indépendamment pour confirmer la nécessité du patchage sur le pfSense+ :
- Le binaire du client DHCP v4 doit être patché pour ne pas avoir à définir la priorité au niveau du VLAN 832 (via l'IHM) qui serait valable pour tout le trafic (et donc ralentissement si j'ai bien vu à droite à gauche) mais au niveau de l'option modifier du client DHCP V4 avec "vlan-pcp 6" sinon parse error du fichier de conf généré par l'IHM.
- Le binaire du client DHCP v6 doit être patché aussi pour obtenir une gateway IPv6 sinon parse error du fichier de conf généré par l'IHM.
Ce qu'ils oublient de dire (ou alors que j'avais pas compris et ce qui m'a fait perdre un peu de temps) sur https://wiki.virtit.fr/doku.php/kb:linux:pfsense:remplacer_sa_box_orange_par_un_pfsense c'est qu'il faut bien attacher ce VLAN 832 à tout "WAN" dans le pfSense, et que les option modifiers qu'on trouve un peu partout *send-interface "igb0"* et *vlan-id 832* ne servent à rien et ne fonctionnent pas que ce soit avec ou sans attacher ce VLAN 832 à WAN par l'IHM. J'ai testé toutes les combinaisons et même un *send-interface "igb0.832"*
Tout le trafic passe donc par le VLAN 832 mais la priorité CoS 6 est seulement définie pour le client DHCPv4 grace au fameux option-modifier "vlan-pcp 6"
J'ai mes 1Gbps symétrique avec ce pfSense+ boitier alu officiel qui n'est même plus en vente car sa MoBo chauffe grave et grille si on ne lui met pas un petit ventilo sur le boitier (j'en ai grillé 1 et un ami grillé 1 aussi et la je tourne avec la dernière révision hard de la MoBo jamais vendue par pfSense pour ce modèle 2 ports)
Et le traditionnel speedtest pour finir. Mon beau 1Gbps symétrique impec sans aucune gigue sur ma robotique temps réel même avec des tonnes de threads contrairement à avec la LB5 en attendant de pousser le vice avec du 10GB
De mon coté en Orange Pro, j'ai voulu passer de PPPOE à DHCP cette aprem. J'y suis depuis 3h. Rien ne fonctionne ...
Je suis par contre quasi sur de bien avoir param comme il le fallait. Est-on sur que l'ensemble des lieux en France permettent de se co en DHCP sur offre Orange Pro ? Y a-t-il des prérequis ?
Ma conf sur opnsense est la suivante :
interface "bxe1_vlan832" {
# DHCP Protocol Timing Values
# DHCP Protocol Options
send dhcp-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox4";
send option-90 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
request subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search, routers,domain-name-servers,option-90;
script "/usr/local/opnsense/scripts/interfaces/dhclient-script";
supersede interface-mtu 0;
}
ou
"bxe1_vlan832" {
# DHCP Protocol Timing Values
# DHCP Protocol Options
send dhcp-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox4";
send option-90 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
request subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search, routers,domain-name-servers,option-90;
send-interface "bxe1";
vlan-id 832;
vlan-pcp 6;
script "/usr/local/opnsense/scripts/interfaces/dhclient-script";
supersede interface-mtu 0;
}
Le résultat :
/sbin/dhclient -c '/var/etc/dhclient_wan.conf' -p '/var/run/dhclient.bxe1_vlan832.pid' 'bxe1_vlan832'
DHCPDISCOVER on bxe1_vlan832 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on bxe1_vlan832 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on bxe1_vlan832 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on bxe1_vlan832 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on bxe1_vlan832 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on bxe1_vlan832 to 255.255.255.255 port 67 interval 9
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
------
J'ai essayer différente config de pcp. Directement sur le VLAN en 6, le VLAN en 0 mais le passage d'option dhcpv4 pour définir en 6 etc.
Rien ni fait, jamais aucune réponse.
-
Je viens de tester mon ONU.
Sur mon offre pro, je n'ai pas le VLAN 832 qui remonte. Est-ce normal ?
Name: ONU_GPE_VLAN_TABLE
ID: 18
no;pcp;dei;vid;vlan_meter_enable;vlan_meter_id;end
32; ; ;2800; ; ;
33; ; ; ; ; ;1
36; ; ;835; ; ;
37; ; ; ; ; ;1
40; ; ;838; ; ;
41; ; ; ; ; ;1
44; ; ;840; ; ;
45; ; ; ; ; ;1
48; ; ;852; ; ;
49; ; ; ; ; ;1
52; ; ;835; ; ;
53; ; ;838; ; ;
54; ; ;840; ; ;
55; ; ;852; ; ;
56; ; ;2800; ; ;
57; ; ; ; ; ;1
-
Il semblerait que sur les anciennes offre orange pro (en livebox 4 pro), la configuration pour avoir les VLAN DHCP n'existe pas et n'est pas remonté en config sur l'ONU.
Seul les nouvelles offres (assez récente) avec la livebox 5 ont des VLAN 832.
J'appel le 3901 demain et je vois avec eux ^^
-
Le plus simple ça reste quand même de rebrancher 5 minutes la box et regarder dans la page diagnostic le mode de connexion…
-
Il semblerait que sur les anciennes offre orange pro (en livebox 4 pro), la configuration pour avoir les VLAN DHCP n'existe pas et n'est pas remonté en config sur l'ONU.
Je ne pense pas. Sur une offre orange pro sans IP fixe assez ancienne (2017-18), la connexion par DHCP est tout à fait possible en IPv4+6.
En revanche l'authentification GPON reste différente (password PLOAM et pas de contrôle du SN).
-
Je viens de tester mon ONU.
Sur mon offre pro, je n'ai pas le VLAN 832 qui remonte. Est-ce normal ?
Name: ONU_GPE_VLAN_TABLE
ID: 18
no;pcp;dei;vid;vlan_meter_enable;vlan_meter_id;end
32; ; ;2800; ; ;
33; ; ; ; ; ;1
36; ; ;835; ; ;
37; ; ; ; ; ;1
40; ; ;838; ; ;
41; ; ; ; ; ;1
44; ; ;840; ; ;
45; ; ; ; ; ;1
48; ; ;852; ; ;
49; ; ; ; ; ;1
52; ; ;835; ; ;
53; ; ;838; ; ;
54; ; ;840; ; ;
55; ; ;852; ; ;
56; ; ;2800; ; ;
57; ; ; ; ; ;1
Le 2800 c'est le VLAN 832.
-
Le 2800 c'est le VLAN 832.
Du coup il faut mettre 832 ou 2800 dans les options de config du vlan du routeur ?
-
Du coup il faut mettre 832 ou 2800 dans les options de config du vlan du routeur ?
C'est toujours 832, 2800 c'est le S-VLAN côté opérateur.
-
Je m'aperçois qu'en passant directement par le boitier blanc (ONT) ça ne fonctionne pas mieux ! Ce n'est donc pas l'ONU (en tout cas pour le moment).
La livebox de son coté parvient bien à récupérer une IP en DHCP.
J'ai fini par faire une capture wireshark des tram DHCP pour vérifier les données entrées. J'ai pourtant bien configurer mon opnsense (déjà fait sur une autre offre).
Mais opnsense ne récup pas l'offre DHCP et donc l'IP.
Orange Pro.
-
En deux mots. MAC address, zone pcp 6 ...
Je vais devoir remettre tout ça au propre maintenant.
Je suis sur OpnSense, j'ai du patcher le client DHCP (dhclient). Si quelqu'un avait le lien d'une version assez récente svp (j'ai pris un truc assez ancien)
@Serveurperso je suis preneur des dernieres info que tu as, en particulier sur le client ipv4 et ipv6 que tu as utilisé. Peux-tu me communiquer les liens stp, afin que je les download ?
-
Bonsoir à tous,
Je viens de repasser chez Sosh après plusieurs moi ailleurs, depuis mon retour je n'arrive pas à obtenir d'IPV4 sur mon routeur Tomato.
Coté DHCP quelque chose à changé ces derniers mois coté orange ?
J'ai tester l'outils sous windows/wine pour récupérer la chaine de caractère de l'option 90 mais rien de concret ...
J'utilise également le vlan 832, voici une partie de ma configuration:
cp -R /sbin/ /tmp/sbin
rm /tmp/sbin/udhcpc
echo 'exec busybox udhcpc -O 0x4d -O 0x5a -x 0x4d: 2b46xxxxxxxxxxxxxxxxxxx (Soit 77 dans le logiciel) -x 0x5a:00000000000000000000001a0900000558010341010d6674692f673675686876323c1260xxxxxxxxxxxxxxxx (Soit 90 dans le logiciel) "$@"' > /tmp/sbin/udhcpc
chmod +x /tmp/sbin/udhcpc
mount --bind /tmp/sbin/ /sbin
Dois-je utiliser 60 et 61 quelque part ?
Mais rien de concret ... coté script Firewall, voici ce que j'ai:
### Version 16 20181010
### https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/
### Priorite / CoS pour Internet
# File 0 (par defaut) pour le DHCP (raw-socket), file 1 pour le reste du trafic
vconfig set_egress_map vlan832 0 6
vconfig set_egress_map vlan832 1 0
### On classe le trafic Internet dans les bonnes files
# Tout le trafic priorite 1 (CoS 0)
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
# Client DHCP non raw-socket (pas le cas de udhcpc) mais sert aussi pour le renew
iptables -t mangle -A POSTROUTING -o vlan832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0000
Merci pour vos lumières
-
Aucun changement depuis l’initiation de ce sujet (et donc la mise en place de l’option 90 longue).
-
Hello @Zoc,
Merci pour ta réponse, je suis re-re passer sur mon ancienne configuration mais sans succès.
Je note deux trois choses différente entre ce que je récupère via le logiciel de @cetipabo et ce que j'avais dans ma conf fonctionelle avant.
De mon coté la chaine DHCP 90 est tronqué, je n'avais pas besoin d'autant de caractère pour que ca fonctionne.
Pour la chaine de caractère 77 pareil, ce n'est plus exactement la même
Ancienne: 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833
Nouvelle: 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
Finalement tout est pareil sauf que ca fini par 33 et la nouvelle par 34.
Une âme charitable pour m'expliquer l'importance de ces chaines de caractères ?
J'ai également un autre changement, je suis repasser sur un ONT propriétaire fournis par SOSH.
Y'a t'il une manipulation spécifique ? Rédémarrage de l'ont après boot du router ? ou autre?
Merci encore pour vos réponses :)
-
Pour la chaine de caractère 77 pareil, ce n'est plus exactement la même
Ancienne: 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7833
Nouvelle: 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
+FSVDSL_livebox.Internet.softathome.Livebox3
+FSVDSL_livebox.Internet.softathome.Livebox4
L'option DHCP 90 version longue, on ne cesse de le répéter dans tous les posts, il faut considérer qu'elle est obligatoire sous cette forme maintenant.
jene comprends pas pourquoi tout le monde va détérer des vieux topic de 2017...il faudrait qu'ils soient mis à jour, ou tout simplement indiquer en 1ere page en haut en rouge, que le tuto n'est plus d'actualité. Ou en faire un nouveau qui commence par [2022].
@zethis j'imagine que "avant" tu n'avais pas non plus besoin de la COS a 6 sur tes requetes DHCP ? car c'est peut être devenu indispensable là ou tu te trouves maintenant.
-
Hello Cetipabo
Merci pour ta réponse, pour compléter un peu, mon tuto était fonctionnel en 2019 et j'ai changé d'opérateur courant 2020, donc pas de mise à jour de mon côté, ce sera fait quand ce sera de nouveau fonctionnel chez moi.
Niveau configuration, j'ai mis tout ce que j'avais plus haut ( a part le fait d'être sur le vlan 832 en mode tag).
Peut tu me rediriger vers un récap des options DHCP et iptables pour que ce soit fonctionnel stp ?
Je vais passer l'option dhcp 90 en mode long et vérifier la version de ma livebox pour être sûr d'utiliser la bonne.
Merci encore pour ta réponse et bon dimanche.
-
Par rapport à ta config qui marchait avant, assure toi d'avoir l'option DHCP90 version longue, et la cos à 6 sur les requetes DHCP. c'est tout, pas plus.
Pour la COS 6 sur ton routeur Tomato, jette un oeil ici : https://www.unicoda.com/?p=3635
### Version 16 20181010
### https://lafibre.info/remplacer-livebox/tuto-remplacer-la-livebox-par-un-routeur-dd-wrt-internet-tv/
### Priorite / CoS pour Internet
# File 0 (par defaut) pour le DHCP (raw-socket), file 1 pour le reste du trafic
vconfig set_egress_map vlan832 0 6
vconfig set_egress_map vlan832 1 0
### On classe le trafic Internet dans les bonnes files
# Tout le trafic priorite 1 (CoS 0)
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
# Client DHCP non raw-socket (pas le cas de udhcpc) mais sert aussi pour le renew
iptables -t mangle -A POSTROUTING -o vlan832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0000
-
Top merci je check tout ça et je fais un retour !
-
Merci à tous pour votre aide, mais rien de plus ce soir après une bonne demie journée de tests, je n'arrive même pas à obtenir une IP en 172.x (je me rapelle en avoir obtenue une dans les débuts de mes tests il y'a quelques années en arrières.) Si jamais quelqu'un a une idée même saugrenue, je prend :)
Encore merci pour votre aide.
Bonne soirée à tous :)
-
Bonjour,
quel Switch est capable de donner du CoS 6 ?
Avec le Netgear GS 308T se n'est plus possible
Cordialement
-
Bonjour,
quel Switch est capable de donner du CoS 6 ?
Avec le Netgear GS 308T se n'est plus possible
Cordialement
Tu peux revenir sur un Firmware "ou c'etait possible" sinon ?
https://www.netgear.fr/support/product/gs308t.aspx#download
-
Bonjour,
merci pour le lien.
j'y pensais à faire ça mais j'avais peur de tout détruire.
dans l'après midi, j'ai pu discuter avec des ingénieurs de SPIE informatique
leur avis au sujet d'un routeur à la place de la box : pas simple à cause de l'adresse MAC
pour eux , un routeur qui pouvait se connecter en 2017 et peut le faire en 2022, c'est son
adresse MAC a été autorisée au début , au moment de la première connexion et mise en mémoire. du coup, le routeur est devenu une lavebox pour Orange.
et ensuite les Zones Grand public et Pro
c'est pour cette raison que je veux régler le problème du QoS en premier
Cordialement
-
Les ingénieurs de chez SPIE ne connaissent pas l’infra d’Orange et en l’état racontent n’importe quoi.
Il n’y a pas de validation d’adresse Mac chez Orange. Et au pire si c’était le cas il suffirait de cloner l’adresse Mac de la livebox sur le port WAN de son routeur perso: n’importe quel routeur digne de ce nom permet de changer l’adresse mac de ses interfaces.
-
Bonjour,
oui, je l'ai vu cette possibilité pour l'IP
je n'arrive pas à me connecter car le WAN n’envoie pas les Options 90 et 77 que j'ajoute dans le Mikrotik elles ne sont pas indiquées comme par défaut avec une "*" contrairement aux autres options
les valeurs sont écrites comme la livebox , la livebox envoie une partie de son IP , juste la fin ( les 4 derniers ) de mémoire car j'ai comparé .
je pense que les Options 60,90 et 77 ne sont pas envoyés par défaut ou sont bloquées par le pare-feu car je ne les vois pas passer quand je regarde ce qui vient du WAN de RouterOs
peut-être depuis une mise à jour qui ne touche que ceux qui se connectent après cette mise à jour , ce qui est mon cas
je n'ai pas les compétences pour les rendre par défaut
J'ai contacté le support Netgear pour la partie CoS 6 , ils ne savaient rien , alors qu'ils vendent des routeurs qui peuvent se connecter à la Fibre Orange France en DHCP
et incapable de me dire quels routeurs , je sais ORBI mais quels ORBI et si les VLAN 832 et 840 sont encore dans le LAN contrairement à la box qui supprime
Mon Switch GS310TP fait bien la liaison entre l'ONT et la livebox5 en CoS 6 car la box envoie en CoS 6 pour le VLAN 832 et CoS 5 pour le VLAN 840 .
l'Analyse direct de l'ONT donne du CoS 5 pour le VLAN 840
je remarque que pour écrire la valeur de l'Option 90 , je vois souvent
00:00:00 ...
ça c'est faut comme écriture en Hexadécimal
la livebox envoie sous cette forme :
0x00000000...
de mon coté, j'ai tout passé en hexadécimal
90, 60 et 77 comme le fait la box donc les seules raisons qui peuvent bloquer la connexion
l'IP non reconnue
Le CoS qui n'est pas à 6
Les Ootions 60, 90 et 77 non envoyées
Si je clone l'IP de la box je ne peux pas la raccorder au routeur pour récupère le téléphone
Cordialement
-
Manifestement vous mélangez tout ( IP et adresse Mac ne sont pas la même chose), ce qui explique pourquoi vous n’arrivez à rien. Sans compétences solides en réseau, autant garder la Livebox….
-
Bonjour,
Non pas du tout, le ne mélange pas IP et MAC , je constate simplement que connecter un routeur en DHCP à la place de la livebox , même en respectant la procédure, ça ne fonctionne plus.
le fabricant est incapable de me donner la référence du produit capable de se connecter à Orange alors qu'il le fabrique et SPIE Informatique me confirme que ce n'est pas possible.
et de mon coté, le routeur n'envoie pas les options réclamés par le DHCP de orange.
il n'y a que les options par défaut qui sortent au niveau du WAN .
-
Mais SPIE n'y connait rien du tout. J'ai connecté un nouvel abonné Orange avec un EdgeRouter ER4 à la place de sa Livebox pas plus tard que mercredi dernier.
Et accessoirement aucun fabriquant de routeur ne pourra donner la procédure pour connecter leur équipement à Orange parce qu'Orange utilise un procédure non standard et NON documentée. Si on y arrive ici c'est parce qu'on est plusieurs à avoir passé nos soirées et week-end à faire du reverse engineering...
-
Bonjour,
je sais bien que vous y passez vos soirées , moi aussi c'est mon cas pour d'autres domaines , le son et la vidéo.
Je vous remercie
Cordialemt
-
Bonjour,
petite question, c'est quoi finalement qu'il faut faire ?
J'ai vu passer des Le fait que à version courte de la chaîne fonctionne est un coup de bol (et du coup ça commence à ne plus fonctionner car Orange commence à vérifier le mdp), aucune Livebox n’a jamais envoyé ce type de chaîne d’authentification. La bonne version c’est fti+salt+hash(salt+mdp).
Ce qui n'est pas ce qui est indiqué sur la FP. Ca a encore changé ?
Merci :)
-
Bonjour,
vous pourriez me dire ce que veut dire : fti+salt+hash(salt+mdp).
fti , je sais , c'est le login
mais salt , hash
et pourquoi ajouter (salt+mdp)
merci
car mon blocage peut être là
-
Utilisez https://jsfiddle.net/kgersen/3mnsc6wy/22/ et vous aurez directement la chaîne longue à utiliser sans avoir à vous poser de question supplémentaire.
-
mais salt , hash
et pourquoi ajouter (salt+mdp)
salt = ensemble d’octets aléatoires (je ne me souviens pas de la longueur)
hash = fonction de hachage appliqué sur le salt concaténé au mot de passe (plus un caractère additionnel non mentionné), en l’occurrence la fonction de hash à utiliser est MD5.
En fait, la chaîne d’authentification est construite en utilisant un algorithme d’authentification similaire à CHAP (https://en.wikipedia.org/wiki/Challenge-Handshake_Authentication_Protocol), mais sans phase de challenge (c’est donc la box qui génère aléatoirement le salt).
car mon blocage peut être là
Non, c’est la CoS des paquets DHCP.
-
Bonjour,
Merci
-
Ou encore plus simple, si votre Livebox est actuellement configurée correctement, vous utilisez liveboxinfos.ga qui vous donnera directement la chaine 'option 90' à utiliser. Et après vous pourrez remercier @cetipabo ;)
Edit Vivien : Version récupérée via Archive.org
Liveboxinfo
LiveBoxInfo 2.0.15 pour LiveBox 3, 4 et 5 (https://lafibre.info/images/routeur/LiveboxInfov2.0.15.zip)
LiveBoxInfo 1.9.5 pour LiveBox 2 (https://lafibre.info/images/routeur/LiveboxInfov1.9.5.zip)
LBMonitor
LBMonitor 2.6.4 pour LiveBox 3 et 4 (https://lafibre.info/images/routeur/LBmonitor2.6.4.zip)
LBMonitor 2.4 pour LiveBox 2 (https://lafibre.info/images/routeur/LBmonitor2.4.zip)
-
Merci !
-
Hello, Je vais bientôt tenter l'aventure de la connexion sans livebox, par un client dhcp comme évoqué sur ce fil ou sur le fil 'remplacer la livebox par dhcp'.
J'ai une carte ethernet avec 4 ports, je compte brancher l'ONT sur un port ethernet et donc me connecter avec client dhcp en suivant les instructions lu ici et la.
j'aimerais quand même pouvoir connecter la livebox sur un autre port ehernet disponible pour avoir accès à la TV et le TEL plus facilement.
Est - ce qu'un simple serveur dhcp sur l'interface ethernet de ma carte réseau connecté à la livebox ferait l'affaire ou c'est beaucoup plus compliqué ?
Est - ce que je perds mon temps car le TEL ne fonctionnera de toute façon pas ou même la TV ?
merci pour tous les renseignements
-
Hello,
il y a quelque temps encore la version courte semblait être acceptée par les serveurs DHCP d'Orange
La version courte, c'est en gros la version longue amputée du salt et du hash du mot de passe (il reste donc le login du client précédé de quelques octets de valeur constante). Elle fonctionne à priori mais ne correspond clairement pas au comportement de la box, preuve que pour l'instant Orange ne vérifie pas le mot de passe. Ca pourrait évidemment changer du jour au lendemain.
Depuis ce matin (probablement l'heure de renouvellement de mon bail DHCP) la connexion m'est refusée avec la version courte.
J'ai récupéré la version longue qu'envoie la LB(4), reconfiguré mon routeur avec, et ça refonctionne.
Il semblerait qu'Orange impose désormais la vérification de mot de passe dans l'option 90 (du moins sur une partie de leur parc).
EDIT 17 mai 2022: une fois de plus la connexion m'est refusée; j'ai du régénérer une option longue.
Je me suis aussi rendue compte que mes options DHCPv6 étaient pas bonnes, et que sur de l'OpenWRT ce qu'il faut spécifier en plus de l'option 11 (équivalent de la 90 mais en v6) c'est 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d 17:000005580006000e495056365f524551554553544544, spécifiquement que l'option 15 doit être en texte car odhcp6c décide d'envoyer l'hexa en texte si on met de l'hexa...
EDIT 3 juin 2022: encore une fois, connexions refusées depuis un certain moment dans la nuit; régénération d'une option et ça repart.
Au vu du rythme auquel je dois faire ça j'ai l'impression qu'une option 90 est valable 1 500 000 secondes, soit 17,361 jours.
-
Bonjour,
Je un souci aussi avec le DHCP Orange (sosh chez moi).
J'utilise la fibre sosh et ce matin j'ai voulu passer sous openWRT (Xiaomi AX3600) via le transsiver fibre orange mais j'ai eu beaucoup de soucis, bon nous sommes passé de iptables à nftables sur ma version de openwrt, mais même en traduisant les règles toujours pas de réponse à ma requéte DHCP.
J'ai copier l'option 90 via livebox info, pas mieux.
root@OpenWrt:~# udhcpc -p /var/run/udhcpc-eth0.832.pid -t 0 -i eth0.832 -x hostname:OpenWrt -V sagem -C -B -R -O 1 -O 15 -O 28 -O 51 -O 58 -O 59 -O 90 -x 61:010887C659B5C0 -x 77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 -x 90:00000000000000000000001a0900000558010341010d6674692f677a616634757a3c124a2f5b7872XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX714
udhcpc: started, v1.35.0
udhcpc: broadcasting discover
udhcpc: broadcasting select for 172.16.150.131, server 80.10.247.48
udhcpc: broadcasting select for 172.16.150.131, server 80.10.247.48
udhcpc: broadcasting select for 172.16.150.131, server 80.10.247.48
Auriez-vous une idée pour m'aider ?
-
ElementW> Etrange, tu es le seul dans ce cas là ?
-
Bonjour,
De mon côté impossible d'avoir une IP (option longue, CoS 6 etc...). J'ai testé sur pfSense et OPNsense, rien n'y fait.
Ça a déjà fonctionné il y a quelques semaines mais là je comprends pas.
Je récupère les options depuis la LB donc peu de chance d'avoir une erreur. Par contre je me suis aperçu que l'option 90 (du moins la partie du hash du mdp) était différente à chaque fois que je voulais revérifier l'option.
J'ignore si c'est normal.
Edit : avec l'option 61 pas mieux.
-
La box change le seed, et donc le contenu de l’option 90, a chaque requête DHCP. Ce n’est pas nouveau, ça a toujours été comme ça avec la chaîne en version longue.
-
La box change le seed, et donc le contenu de l’option 90, a chaque requête DHCP. Ce n’est pas nouveau, ça a toujours été comme ça avec la chaîne en version longue.
OK merci donc c'est bien normal et d'une certaine manière ce n'est pas illogique.
Par contre je ne comprends pas pourquoi je n'obtient toujours pas d'IP.
Nous sommes bien d'accord que seuls ces éléments sont nécessaires ?
Option 60 : 736167656d
Option 77 : 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
Option 90 : 00000000000000000000001a090000055801034......... Option longue
Request Options : subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search,routers,domain-name-servers,option-90
Option Modifiers : vlan-pcp 6
J'ai déjà pu avoir une IP il y a quelques semaines avec cette conf donc je sais que quelque chose a changé.
J'ai aussi essayé de pousser l'adresse MAC avec l'option 61 et le 01 devant (de toute façon je sniff la box donc je ne fait que du copier coller à ce niveau) mais rien de mieux.
-
Hello même problème pour moi debut mon déménagement (début mars), nouvelle ligne de A-Z (numéro de client, boitier fibre inexistant car logement neuf, etc ...)
Impossible d'obtenir une ip (en 172 de la part de l'ONT ou une ip publique)
J'ai essayer les différentes façon de conversion pour l'option 60, 77 & 90, mais sans résultats.
En revanche j'ai remarqué qu'a chaque redémarrage ou déconnexion/reconnexion au wan, les différentes option générée avant ne sont plus les mêmes.
Je n'ai aucune idée de la façon de debugger ça ... si vous avez des pistes je suis preneur :)
Merci et bon weekend !
-
La CoS (802.1p, pas DSCP) pour les paquets DHCP est bien à 6 ? (Obligatoire dans le 06). Voir mon post précédent pour les option qui changent: ça a toujours été comme ça avec la livebox.
-
Hello Zoc,
Merci pour ta réponse, je suis passer dans le 83 maintenant, proche 06 cette mais 83.
Tu peux me linker ton post stp ?
Merci
-
Je pense que mon message a mal été interprété: Mon post précédent, c'est celui un peu plus haut qui explique que l'option 90 change à chaque requête quand c'est la Livebox qui s'authentifie, que ça a toujours été comme ça, et que ça fonctionne quand même si on utilise plusieurs fois la même chaine.
-
Les personnes ayant ajouté du contenu ici pourraient elles répondre en dessous de mon message afin de lister les générateurs, info utiles, manières automatiques [etc.] afin que j'update la première page avec le contenu le plus a jour possible ?
Merci ^^
-
Un script shell qui fait bien le travail existe également.
-
Suite à une panne ou des travaux ce matin dans mon quartier, j’ai perdu ma connexion et malgré une reattribution d’IP (4 et 6), je n’ai plus internet. D’après Orange, je suis bien connecté mais je n’ai pas de session ouverte.
J’ai essayé le script posté juste au dessus pour régénérer mon option 90 mais il échoue avec l’erreur 15: Bad substitution.
Je n’ai rien changé à la configuration depuis plusieurs année et ça fonctionnait très bien. Je n’ai pas de Livebox donc plus internet chez moi tant que je ne trouve pas de solution.
-
Je n’ai rien changé à la configuration depuis plusieurs année...
justement il est peut etre là le problème ;D tu n'avais peut etre pas besoin de la cos 6 avant et maintenant elle est devenue obligatoire dans ton secteur peut etre ?
sinon pour l'option 90 utilise ce lien : https://jsfiddle.net/kgersen/3p854b9e/
-
Bon, déjà, je n’avais pas le salt dans mon option 90/11. Par contre, pas compris ce qu’était le byte.
Pour le cos, c’est au niveau du Vlan 832 que ça se change ? Ça correspond au VLAN priority (sur Best Effort 0 jusqu’à présent chez moi) qu’il faut passer sur Internetwork Control 6 ?
PS: ce site est une plaie sur mobile !
-
Pour info le script de generation quelque post au dessus ne fonctionne pas pour moi non plus.
J'ai du passer la ligne
h=3C12$(tohex ${r})0313$(tohex ${id})$(echo -n ${id}${pass}${r} | md5sum | cut -c1-32)en
h=3C12$(tohex ${r})0313$(tohex ${id})$(echo -n ${id}${pass}${r} | md5sum | cut -c1-30)
En comparant ce que donnait le code avec 32 et une capture de trame de ma livebox, le code avec 32 me donnait un code hexa en trop !
-
Hello,
Est ce que cela ne fonctionne PAS ou bien PLUS ?
Cela a t-il fonctionner avant ?
Merci.
-
J’ai essayé le script posté juste au dessus pour régénérer mon option 90 mais il échoue avec l’erreur 15: Bad substitution.
Bonjour,
Peut-être l'avez-vous déjà fait, il faut remplacer les astérisques par votre identifiant après « fti/ » et votre mot de passe, puis donner les droits d'exécution avec la commande chmod. Dans le powershell de windows ça ne marche pas. Il faut l'exécuter dans la console Linux ou Unix munie d'un shell avec Bash. Ça ne marchera pas avec Korn shell ou C shell. L'erreur 15 est « normale ». Le shell par défaut des distributions de type Debian est dash et non bash. Il faut donner les droits d'exécution 755 puis lancer le script :
./rfc3118.sh
Je ne l'ai pas exécuté depuis longtemps mais si Orange n'a fait aucun changement, la bonne chaîne d'authentification au format hexadécimal devrait être générée.
-
En comparant ce que donnait le code avec 32 et une capture de trame de ma livebox, le code avec 32 me donnait un code hexa en trop !
Merci, c'est bon à savoir.
Avec "30" ça marche ou pas ?
-
J’ai réussi à utiliser le script, mais ça ne change rien. C’est même pire quant vu que je n’obtiens plus que IPv4 et plus d’IPv6 et toujours aucun site d’accessible, impossible de joindre la moindre machine sur internet même via son IP.
Du coup, je viens de demander une migration vers OHV, moins cher pour un meilleur débit et au moins, utiliser son propre routeur est prévu. Par contre, deux semaines sans internet, ça va être difficile !
-
J’ai réussi à utiliser le script, mais ça ne change rien. C’est même pire quant vu que je n’obtiens plus que IPv4 et plus d’IPv6 et toujours aucun site d’accessible, impossible de joindre la moindre machine sur internet même via son IP.
Du coup, je viens de demander une migration vers OHV, moins cher pour un meilleur débit et au moins, utiliser son propre routeur est prévu. Par contre, deux semaines sans internet, ça va être difficile !
Remets la livebox en attendant ;D
-
J’ai réussi à utiliser le script, mais ça ne change rien. C’est même pire quant vu que je n’obtiens plus que IPv4 et plus d’IPv6 et toujours aucun site d’accessible, impossible de joindre la moindre machine sur internet même via son IP.
Avez-vous bien défini la CoS ou Class of Service ?
-
Remets la livebox en attendant ;D
Notre ami Éditech a écrit plus haut qu'il n'a plus de Livebox.
-
Notre ami Éditech a écrit plus haut qu'il n'a plus de Livebox.
J'ai raté l'info, ma faute :-X
Sinon, si tu n'obtiens même pas une IP en 172.19.X.X c'est que ce n'est pas qu'un problème de contenu sur l'option 90.
N'hésite pas à consulter ce topic qui condense bien les changements : https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/
-
En changeant le 32 par 30, j’ai une adresse en 172 (82 sinon).
Je ne sais pas où modifier ce fameux cos sous Opnsense.
-
Bon, en utilisant l'adresse IP en 82, en mettant 6 dans le VLAN et en rebootant le routeur, ça a bien voulu fonctionner !
Donc c'est bon, tout fonctionne.
Merci pour votre aide.
-
PS: ce site est une plaie sur mobile !
Si tu as un bug, écris à Vivien ou décris le dans un post de la section idoine. Il est très réactif et trouvera probablement une solution :)
-
Bon, en utilisant l'adresse IP en 82,
j'ai bien peur de ne pas comprendre cette partie
-
Désolé, ce n'était pas clair. Avec le script pour générer l'option 90, si je l'utilise tel quel (avec 32 à la fin), ça m'attribue une adresse IPv4 commençant par 82, 172 si je change pour 30 (quelqu'un ici devait changer 32 en 30 pour que ça fonctionne).
Donc avec l'option 90 correcte, j'ai une IPv4 commençant par 82 et donc là, avec 6 pour le VLAN priority, en rebootant le routeur, ça fonctionne.
D'ailleurs, j'ai récupéré la même IPv4 et la même IPv6 qu'avant mes problèmes, ce qui me surprend un peu.
-
Hello,
tu as très certainement rencontré un problème de DUID ou de lease temporaire avec l'infra Orange.
c'est normal de récupéré une adresse en autre chose que 172.x.x.x, cette dernière est privé, non routable. Quand tout fonctionne, tu récupéres une IP publique du range Orange (82.x.x.x par exemple).
Donc, il ne faut pas changer le script.
-
Désolé, ce n'était pas clair. Avec le script pour générer l'option 90, si je l'utilise tel quel (avec 32 à la fin), ça m'attribue une adresse IPv4 commençant par 82, 172 si je change pour 30 (quelqu'un ici devait changer 32 en 30 pour que ça fonctionne).
Logiquement, c'est 32 caractères et non 30. Notre ami MASTAH a trouvé qu'avec 30 caractères c'était mieux dans son cas. Il doit avoir une IP commençant avec l'octet 172, qui est, comme l'écrit crayon, une IP privée de la plage 172.16.0.0 à 172.31.255.255, qui appartient à la classe B et utilisée dans les LAN, Orange attribue des IP publiques. L'IP commençant par l'octet 82 est le résultat d'une bonne configuration de l'option 90. Bravo !
-
Bonjour à tous,
petit retour d'expérience de mon côté.
J'ai remplacé ma livebox par un Ubiquiti EdgeRouter X depuis 4 ou 5 ans maintenant. A l'époque déjà je me rappelle que la partie DHCP m'avait pas mal embêté :)
Il y a 10j, il y a eu une coupure de maintenance sur ma connexion fibre (tout le quartier, je pense à cause des nouveaux logements qui sont livrés), et jeudi dernier (2 mars) dans la nuit, ma connexion est tombée. Impossible d'obtenir une IP publique.
Heureusement je garde ma LB sous la main au cas où (bon j'ai du appeler le support Orange quand même, quand j'avais mis un mauvais fti/xxx ......)
Ce matin, en voulant réinstaller mon router Ubiquiti, j'ai regardé ce forum, mais aucune des solutions proposées (le script sh, ou le jsfiddle) n'ont fonctionnés pour moi.
Du coup, j'ai branché la prise WAN de la LB directement sur mon PC pour faire une capture de paquets et récupérer les valeurs des options DHCP, notamment l'option 90. Après un copier/coller, ça fonctionne.
-
Et il y a cela : https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/
-
Ce matin, en voulant réinstaller mon router Ubiquiti, j'ai regardé ce forum, mais aucune des solutions proposées (le script sh, ou le jsfiddle) n'ont fonctionnés pour moi.
Du coup, j'ai branché la prise WAN de la LB directement sur mon PC pour faire une capture de paquets et récupérer les valeurs des options DHCP, notamment l'option 90. Après un copier/coller, ça fonctionne.
Etrange, le jsfiddle marche à tous les coups normalement. Ils ont par contre implémenté pas mal de restrictions sur le nombre de sessions/DUID/adresses MAC actives sur un port, et à priori dans certains cas, le seul moyen de libérer de la place dans les sessions actives, c'est d'attendre l'expiration du bail (en partant du principe que tu ne peux pas faire de DHCP release, ce qui est le cas avec la livebox).
Dans mes confs DHCP, à part les options 11/90, je n'ai rien changé. J'avais cloné l'adresse MAC de la livebox il y a plusieurs années et n'ai jamais eu de souci... en même temps, je n'ai ressorti la livebox que deux fois après déménagement, pour montrer au technicien que la connexion était opérationnelle.
-
Pour ceux que ça intéresse, voici un fichier Excel (M365) + le module VBA pour calculer l'option 90.
PS : la formule en H2 c'est : ="0000000000000000000000"&"1a09"&"00000558010341"&"010d"&I3&"3c12"&I6&"0313"&I5&I7
J'ai remplacé le fichier Excel...
-
Logiquement, c'est 32 caractères et non 30. Notre ami MASTAH a trouvé qu'avec 30 caractères c'était mieux dans son cas. Il doit avoir une IP commençant avec l'octet 172, qui est, comme l'écrit crayon, une IP privée de la plage 172.16.0.0 à 172.31.255.255, qui appartient à la classe B et utilisée dans les LAN, Orange attribue des IP publiques. L'IP commençant par l'octet 82 est le résultat d'une bonne configuration de l'option 90. Bravo !
Bonjour,
Personnellement, IP en 172.16.x.x avec option 90/11 sur 32 octets générée par le script du forum (et accès non fonctionnel), et IP publique obtenue immédiatement avec option 90/11 sur 30 octets fournie par le petit soft LiveboxInfo. Et en comparant avec le site https://jsfiddle.net/kgersen/3p854b9e/ (https://jsfiddle.net/kgersen/3p854b9e/), celui-ci me génère aussi une option 90/11 sur 30 octets.
-
Bonjour à tous,
petit retour d'expérience de mon côté.
J'ai remplacé ma livebox par un Ubiquiti EdgeRouter X depuis 4 ou 5 ans maintenant. A l'époque déjà je me rappelle que la partie DHCP m'avait pas mal embêté :)
Il y a 10j, il y a eu une coupure de maintenance sur ma connexion fibre (tout le quartier, je pense à cause des nouveaux logements qui sont livrés), et jeudi dernier (2 mars) dans la nuit, ma connexion est tombée. Impossible d'obtenir une IP publique.
Heureusement je garde ma LB sous la main au cas où (bon j'ai du appeler le support Orange quand même, quand j'avais mis un mauvais fti/xxx ......)
Ce matin, en voulant réinstaller mon router Ubiquiti, j'ai regardé ce forum, mais aucune des solutions proposées (le script sh, ou le jsfiddle) n'ont fonctionnés pour moi.
Du coup, j'ai branché la prise WAN de la LB directement sur mon PC pour faire une capture de paquets et récupérer les valeurs des options DHCP, notamment l'option 90. Après un copier/coller, ça fonctionne.
Idem pour moi. J'ai fait la même chose suite à des conseils de la communauté et ça fonctionne maintenant, mais pas à partir de jsfiddle...
-
je vous mets un générateur d'option DHCP 90 utilisable offline. il y a 2 parfums, avec séparateur ":" et sans séparateur.
Le code source autoit est fourni si vous voulez le modifier ou le faire évoluer.
(https://i.imgur.com/GW3BqcO.png)
je me suis basé sur le jsfiddle pour le faire sous autoit. Et j'ai repris l'exemple fourni par ubune dans son topic Openwrt (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/) pour vérifier le résultat obtenu :
(https://i.imgur.com/E9sMXa5.png)
-
Bonjour,
ou trouver son mot de passe fibre ?
je n'en ai pas , c'est la PTO ?
on me dit qu'il n'y en a pas , la box le reçoit automatiquement à la première connexion.
Merci
-
ou trouver son mot de passe fibre ?
Il est sur la lettre de bienvenue que tu as recue avec la Livebox, normalement.
-
Bonjour,
j'étais en ADSL Orange et je suis passé à la fibre avec un commercial qui est venu chez moi.
dans le carton, il y avait bien un courrier mais pas de mot de passe de connexion pour la livebox
juste que l'identifiant de la messagerie ne changeait pas . normal, je suis resté chez orange .
mon père est chez free pour la fibre et c'est la même chose , pas de mot de passe .
en ADSL oui, il y avait un mot de passe .
je vais contacter Orange
Cordialement
-
Bonjour simon ,
Merci de ton message, j'ai contacté le 3900 et Orange me l'envoie par courrier.
:)
Cordialement
-
Bonjour,
pour avoir toutes les infos, c'est quoi le " Salt " ?
comme information .
Cordialement
-
C'est une chaine aléatoire qui est ajoutée (avant ou après je ne sais plus) le mot de passe avant de calculer son hash.
-
Bonjour,
je vais me débrouiller
merci beaucoup
-
Salut,
Je ne sais pas si il y avait déjà une version Windows Powershell pour générer l'option authsend 90.
$login='fti/xxxxxxx';
$pass='xxxxxxx';
[Reflection.Assembly]::LoadWithPartialName("System.Web");
function ToMD5($s) {
return [System.Web.Security.FormsAuthentication]::HashPasswordForStoringInConfigFile($s, "MD5");
}
function ToHex($s) {
return $($s.ToCharArray() | ForEach-Object { [BitConverter]::ToString([byte]$_) }) -join '';
}
$r = $(ToMD5($login)).Substring(0,16);
$id=$r.Substring(0,1);
$h="3C12" + $(ToHex($r)) + "0313" + $(ToHex($id)) + $(ToMD5("$id$pass$r"));
$authsend = "00000000000000000000001A0900000558010341010D" + $(ToHex($login)) + $h;
Write-Host "0x$authsend".ToLower() -ForegroundColor Red;
Résultat
0x00000000000000000000001a0900000558010341010d6674692f787878787878783c1239394333454642333134433839464635031339b79f443416f119710ffe6b53b75e4fd8
-
Je ne sais pas si une version bash a été proposée :
#!/bin/bash
OLOGIN="fti/xxxxxxx"
OPASSWORD="yyyyyyy"
tohex() {
for h in $(echo $1 | sed "s/\(.\)/\1 /g"); do printf %02x \'$h; done
}
addsep() {
echo $(echo $1 | sed "s/\(.\)\(.\)/:\1\2/g")
}
# 16 char hex aleatoires (SALT)
r=$(dd if=/dev/urandom bs=1k count=1 2>&1 | md5sum | cut -c1-16)
# le 1er char du Salt
id=${r:0:1}
h=3C12$(tohex ${r})0313$(tohex ${id})$(echo -n ${id}${OPASSWORD}${r} | md5sum | cut -c1-32)
echo 0x00000000000000000000001A0900000558010341010D$(tohex ${OLOGIN})${h}
#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 ${OLOGIN})${h})
On peut commenter/décommenter les 2 dernières lignes selon le format de sortie désiré (0x0000... ou 00:00:...)
-
Bonjour,
J'ai des difficultés avec l'IPV6 sur pfsense. Je pense que c'est le DUID qui me pose problème, car il ne semble pas s'enregistrer dans l'interface et ma capture tcpdump montre un préfixe différent envoyé, ainsi que mon mac.
Cela doit être "00:03:00:01:01:<MAC>" n'est-ce pas ?
Merci pour toute aide concernant pfsense
-
"00:03:00:01:<MAC>"
Ensuite, la MAC doit être cohérente avec le dhcp-client-identifier (option 61) envoyé en IPv4 et l'interface physique.
Toutes les infos sont dans le topic Orange DHCP conformité protocolaire 2023 (https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/)
-
Merci hj67, mon problème était précisément de savoir comment spécifier le duid brut dans pfsense, car il n'accepte pas un duid brut complet en entrée. Je ne sais pas si c'est un bug, ou si c'est comme ça que c'est censé être. Quoi qu'il en soit, j'ai contourné le problème en créant le fichier dhcp6c_duid correct dans opnsense et en le copiant, et je peux voir que dhcp6c reconnaît maintenant le duid correct.
Cependant, je n'ai toujours pas de succès avec ipv6.
Dans le syslog, je vois ces erreurs liées à dhcp6c et j'ai donc enquêté davantage, mais je n'arrive pas à comprendre ce qui cause cette erreur de syntaxe. Une idée ?
Merci pour tout conseil sur ce sujet avec pfsense !
Dec/25/2023 13:31:00: /var/etc/dhcp6c.conf 3: syntax error
Dec/25/2023 13:31:00: /var/etc/dhcp6c.conf 3: fatal parse failure: exiting (1 errors)
[2.7.2-RELEASE][root@pfSense.home]/root: dhcp6c -Df -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid re0.832
Dec/25/2023 13:31:00: extracted an existing DUID from /var/db/dhcp6c_duid: 00:03:00:01:XX:XX:XX:XX:XX:XX
Dec/25/2023 13:31:00: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Dec/25/2023 13:31:00: failed initialize control message authentication
Dec/25/2023 13:31:00: skip opening control port
Dec/25/2023 13:31:00: <3>[interface] (9)
Dec/25/2023 13:31:00: <5>[re0.832] (7)
Dec/25/2023 13:31:00: <3>begin of closure [{] (1)
Dec/25/2023 13:31:00: <3>[send] (4)
Dec/25/2023 13:31:00: <3>[ia-pd] (5)
Dec/25/2023 13:31:00: <3>[0] (1)
Dec/25/2023 13:31:00: <3>end of sentence [;] (1)
Dec/25/2023 13:31:00: <3>[send] (4)
Dec/25/2023 13:31:00: <3>[raw-option] (10)
Dec/25/2023 13:31:00: /var/etc/dhcp6c.conf 3: syntax error
Dec/25/2023 13:31:00: /var/etc/dhcp6c.conf 3: fatal parse failure: exiting (1 errors)
Dec/25/2023 13:31:00: failed to parse configuration file
Ici, ma valeur hexagonale pour l'option raw 11 est identique à mon option dhcp 90 qui fonctionne bien.
Pour le DUID et le dhcp-client-identifier [61], j'utilise l'adresse MAC de mon interface pfsense sfp, et non celle de la livebox. Je suppose que c'est correct, car cela fonctionne pour l'ipv4, mais corrigez-moi si c'est faux.
[2.7.2-RELEASE][root@pfSense.home]/root: cat /var/etc/dhcp6c.conf
interface re0.832 {
send ia-pd 0;
send raw-option 15 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:4c:69:76:65:62:6f:78:36;
send raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d;
send raw-option 6 00:0b:00:11:00:17:00:18;
send raw-option 11 XX:XX:XX;
script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh";
};
id-assoc pd 0 { };
[2.7.2-RELEASE][root@pfSense.home]/root: dhcp6c -Df re0.832
Dec/25/2023 13:31:43: extracted an existing DUID from /var/db/dhcp6c_duid: 00:03:00:01:XX:XX:XX:XX:XX:XX
Dec/25/2023 13:31:43: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Dec/25/2023 13:31:43: failed initialize control message authentication
Dec/25/2023 13:31:43: skip opening control port
Dec/25/2023 13:31:43: cfparse: fopen(/usr/local/etc/dhcp6c.conf): No such file or directory
Dec/25/2023 13:31:43: reset a timer on re0.832, state=INIT, timeo=0, retrans=891
Dec/25/2023 13:31:44: Sending Solicit
Dec/25/2023 13:31:44: a new XID (30ba54) is generated
Dec/25/2023 13:31:44: set client ID (len 10)
Dec/25/2023 13:31:44: set elapsed time (len 2)
Dec/25/2023 13:31:44: send solicit to ff02::1:2%re0.832
Dec/25/2023 13:31:44: reset a timer on re0.832, state=SOLICIT, timeo=0, retrans=1091
Dec/25/2023 13:31:44: receive advertise from fe80::ba0:bab%re0.832 on re0.832
Dec/25/2023 13:31:44: get DHCP option server ID, len 10
Dec/25/2023 13:31:44: DUID: 00:03:00:01:a0:f3:e4:59:7a:30
Dec/25/2023 13:31:44: get DHCP option client ID, len 10
Dec/25/2023 13:31:44: DUID: 00:03:00:01:XX:XX:XX:XX:XX:XX
Dec/25/2023 13:31:44: get DHCP option status code, len 2
Dec/25/2023 13:31:44: status code: unspec failure
Dec/25/2023 13:31:44: server ID: 00:03:00:01:a0:f3:e4:59:7a:30, pref=-1
Dec/25/2023 13:31:44: reset timer for re0.832 to 0.991258
Dec/25/2023 13:31:45: picked a server (ID: 00:03:00:01:a0:f3:e4:59:7a:30)
Dec/25/2023 13:31:45: Sending Request
Dec/25/2023 13:31:45: a new XID (de349f) is generated
Dec/25/2023 13:31:45: set client ID (len 10)
Dec/25/2023 13:31:45: set server ID (len 10)
Dec/25/2023 13:31:45: set elapsed time (len 2)
Dec/25/2023 13:31:45: send request to ff02::1:2%re0.832
Dec/25/2023 13:31:45: reset a timer on re0.832, state=REQUEST, timeo=0, retrans=909
Dec/25/2023 13:31:45: receive reply from fe80::ba0:bab%re0.832 on re0.832
Dec/25/2023 13:31:45: get DHCP option server ID, len 10
Dec/25/2023 13:31:45: DUID: 00:03:00:01:a0:f3:e4:59:7a:30
Dec/25/2023 13:31:45: get DHCP option client ID, len 10
Dec/25/2023 13:31:45: DUID: 00:03:00:01:XX:XX:XX:XX:XX:XX
Dec/25/2023 13:31:45: get DHCP option status code, len 2
Dec/25/2023 13:31:45: status code: unspec failure
Dec/25/2023 13:31:45: dhcp6c Received REQUEST
Dec/25/2023 13:31:45: status code: unspec failure
Dec/25/2023 13:31:45: removing an event on re0.832, state=REQUEST
Dec/25/2023 13:31:45: removing server (ID: 00:03:00:01:a0:f3:e4:59:7a:30)
Dec/25/2023 13:31:45: got an expected reply, sleeping.
"00:03:00:01:<MAC>"
Ensuite, la MAC doit être cohérente avec le dhcp-client-identifier (option 61) envoyé en IPv4 et l'interface physique.
Toutes les infos sont dans le topic Orange DHCP conformité protocolaire 2023 (https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/)