Remplacer la LiveBox par un routeur => Discussion démarrée par: levieuxatorange le 07 novembre 2022 à 17:00:16 Remplacer la LiveBox par un routeur => Discussion démarrée par: levieuxatorange le 07 novembre 2022 à 17:00:16DHCPv4 :
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: 44d454XXXXXX
l'encodage Hexa de ce qui est ci dessus : 3d 07 01 44 d4 54 XX XX XX
DHCPv6:
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
l'encodage Hexa de ce qui est ci dessus : 00 01 00 0a 00 03 00 01 44 d4 54 XX XX XX
Comme indiqué dans l'encodage des RFC Dynamic Host Configuration Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x6ac82ac7
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: 44:d4:54:XX:XX:XX
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
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
Option: (61) Client identifier
Option: (77) User Class Information
Option: (90) Authentication
Option: (255) End
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x1eace9
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0000
Elapsed time: 0ms
Option Request
Option: Option Request (6)
Length: 8
Value: 000b001100170018
Requested Option code: Authentication (11)
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Identity Association for Prefix Delegation
Authentication
Option: Authentication (11)
Length: 70
Value: 00000000000000000000001a0900000558010341010dXXXX…
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 1a0900000558010341010dXXXX…
User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c697665626f782e496e7465726e65…
Vendor Class
Option: Vendor Class (16)
Length: 11
Value: 0000040e0005736167656d
Enterprise ID: SAGEMCOM SAS (1038)
vendor-class-data: sagem
Bonjour
Le parcage n'est pas définitif, il est purement dynamique.
Un simple reboot / redémarrage des stack v4/v6 en respectant le protocole et les champs 90/11 correct permet d'en sortir.
Aucun appel au 3900 n'est nécessaire (3900 qui ne soutient que un client avec une LB)
Sur les demandes de soutien et d'évolution, le point d'entré sera la responsable Market Orange Grand Public
levieux
Bonsoir,
J'essaie de comprendre un peu le durcissement de l'option 90 avec la prise en compte du password.
Quand on passe par le générateur, il y a 2 champs : SALT et Byte.
Je ne comprends pas ce que l'on doit y mettre la dedans, quelqu'un peut m'expliquer ?
Merci par avance
Neo
- IPv6 : SARR + RENEW / REBIND + RELEASEPour IPv6 : peut-on continuer à utiliser rapid commit (seulement SR au lieu de SARR) ?
respecter les cycle de vie définis dans les RFC idoines et relancer depuis le DORA / SARR en cas de perte de la connectivité montante (à tester avec ARP et ICMPv6 NS/NA) comme le fait la LiveBox
Pour IPv6 : peut-on continuer à utiliser rapid commit (seulement SR au lieu de SARR) ?Jamais tenté en qualif, aucune idée.
Jamais tenté en qualif, aucune idée.
Si tu as une capture de ton échange, donne moi cela en MP, je vais jeter un oeil.
Par contre c'est mieux si on respect le cas "standard simple" SARR. (et DORA en v4)
Edit :
J'ai eu ma réponse : pas supporté dans la config
Pour la posterité, pour ceux qui utilisent un routeur Mikrotik, il faudra désactiver "rapid commit" :Merci pour l'info.
Merci pour l'info.
Par rapport à ton screen, j'ai l'option use Peer DNS de cochée, c'est grave doctor ? (actuellement ça fonctionne comme ça)
Merci. Pour la posterité, pour ceux qui utilisent un routeur Mikrotik, il faudra désactiver "rapid commit" :
EDIT: si je ne m'abuse, tant que tu recois des réponses DHCP de la part d'Orange (peu importe les adresses IP obtenues), pas besoin de chercher côté CoS.
Premier bloc de migration dans un pilote (plusieurs endroits en France)
/system logging
add topics=dhcp
Dans la réponse DHCP, il y a une option 125 en retour dans le format avec en rouge 2 octets de code d'information : 0001000000ffffffffffDHCP v4 je suppose. A-t-on la même chose côté DHCPv6 et si oui, dans quelle option (Vendor-specific Information Option, 17 ?) ?
DHCP v4 je suppose. A-t-on la même chose côté DHCPv6 et si oui, dans quelle option (Vendor-specific Information Option, 17 ?) ?Le mapping des erreurs est le même en DHCPv4 et DHCPv6
Le mapping des raisons que tu as donné sont-ils les mêmes en DHCPv6 ?
Sais-tu si il y a d'autres évolutions prévues à moyen terme, ou est-ce qu'on peut considérer que les configs propres vont rester fonctionnelles pour un bon bout de temps ? (si tu as le droit de communiquer la dessus, bien évidemment)
Peut-on affirmer que l'apparition de l'option 17 en IPV6 correspond à la mise en place de ce nouveau système de contrôle sur la ligne ?
Ce matin j'ai perdu ma connecitivé (paris), je suis potentiellement dans une zone impacté par les changement ?
Pour les options 90/11 normalement je les respects correctement !
Il semblerait que ce n'était que mes option 90/11 dhcp4/dhcp6 qui datant de 10mois ne passaient plus.
J'ai simplement régénérer de nouvelles valeurs et le handshake DHCP était ok.
Sait-on si Orange blacklist / ban / empêche l'authentification si les valeurs option 90/11 sont trop ancienne ?
Le prochain gros morceaux sera la mise en place de CGN DS-LITE pour privilégier l'IPv6 et partager les Ipv4.
Je dirais un bon quelques années avant que cette partie là (CGN) se mette en place en pilote puis se généralise
Dommage de pas avoir retenu le A+P à la Free ça permet au moins d'utiliser en partie l'IPv4.
Pour SFR et Bouygues c'est du DHCPv4 sur la patte WAN, donc à priori pas de tunnel.
Cela dépend des choix réseaux. On a regardé aussi en profondeur (entre autres trucs) pour finalement rester sur le CGN + DS-Lite
On peut cependant diverger d'avis avec les ingé des autres opérateurs. Et la meilleurs solution pour l'un ne l'est peut être pas dans le contexte d'un autre.
J'ai vu un thread sur l'IPv6 sur le forum, une discussion des avantage de MAPE+T versus DS-LITE versus NAT444 doit se tenir là bas si vous voulez
LeVieux
Enfin, espérons que d'ici 15 ans, on ne soit plus obligé d'utiliser l'IPv4 en entrée.
T'es DEJA plus obligé.
Moi j'ai une config (que je détaillerais dans un autres thread) en IPv6 + DynDNS (GnuDIP pour être précis) + Certificat Let's Encrypt et cela marche très bien. J'héberge un HASS + mes configs xxx2mqtt + mon serveurs de fichiers + serveur VPN
Le tout en SLAC dans mon réseau local et en préfix dynamique (préférentiel chez Orange qui change peux voir très peux)
J'hésite même à fermer mon DualStack et couper l'IPv4 comme mon mobil est maintenant en IPv6 chez Sosh.
Pas de ban dans cette version (la "A") du protocole d'auth si le jeux d'options est vieux.
C'est idéalement mieux de changer le challenge à chaque cycle DHCP complet (au redémarrage d'un DISCOVERT ou SOLLICIT) mais ce n'est pas obligatoire
Elles n'étaient peut-être pas correctes avant, et elles sont mieux validées maintenant ?
Peut être une erreur de copier coller ou une nouvelle version du générateur.
En effet, maintenant le contenu de l'option est vérifié dans son intégralité entre login et password. Et plus identifiant de ligne et login.
Le Vieux
Jamais changé mes option 90/11 depuis septembre 2018...
... Bon, après, perso je ne joue pas avec des ONT non fournis par Orange...
J'ai le salt + password depuis septembre 2018 ;). La seule différence avec une box c'est donc que mes chaines sont fixes (plus difficile de mettre en place une génération automatique sans un gros patch de dhclient).
A priori d'après levieuxatorange, ils ne sont pas près de vérifier le caractère aléatoire qui change à chaque renew, heureusement car ça mettrait pas mal de monde dans le caca ;D
Déjà il serait interessant d’avoir une explication sur l’intérêt de cette complexité
Il y a tant de monde qui pollue le réseau sur la patte WAN de l’infra GP d’Orange au point de poser un risque de sécurité ou qui fait apparaître des problèmes de performances ?
Ou c’est simplement pour décourager le « geek » moyen de brancher n’importe quoi et de limiter les appels hotline pour des problèmes liés à du matériel « tiers » ?
Ici l'objectif est de vous aider à faire marcher les configurations.
Concrètement, avec les durcissements à venir, il faudra changer le sel à chaque renew ? Le sel sera imposé par Orange ? (si oui, comment le sel sera communiqué au client dhcp ?)
Ou alors il s'agit simplement d'utiliser une option 90 longue et le même sel en IPv4 et v6, avec possibilité de réutilisation du sel ?
Je pense avoir compris, le SALT c'est la serie de caractères qui sert à MD5 le password.
Ca s’applique aussi aux livebox pro ?
Ca s’applique aussi aux livebox pro ?Les lignes Pro sont portée par les lignes grand public donc oui pour tout ce qui est Livebox Pro (qq soit la génération)
Bonjour
J'ai une question au sujet de la COS6 des packets DHCP.
Pourquoi dans certaines régions il faut une COS6 et ce n'est pas national ? Quelle est la raison technique ? Cela va t-il changer ?
Dois-je aussi inclure ARP et ICMP NS/NA ?Oui, sinon en cas de charge importante longue, le BNG peut perdre la visibilité de votre routeur et vous déconnecter
Oui, sinon en cas de charge importante longue, le BNG peut perdre la visibilité de votre routeur et vous déconnecter
LeVieux
Chez moi pas de TV sans CoS sur IGMP. Par contre ARP/ICMP en Cos0 pas d'effet négatif notable depuis 4 ans et trop compliqué à mettre en oeuvre sur mon routeur. On verra bien ce qui se passe...
840
Ok, merci.
Maintenant me reste à trouver comment faire ca sur du mikrotik...
/interface/bridge/filter >
add action=set-priority chain=output mac-protocol=arp new-priority=6 \
out-interface=vlan832-orange-internet passthrough=yes
add action=set-priority chain=output comment=NA/NS mac-protocol=ipv6 \
new-priority=6 out-interface=vlan832-orange-internet packet-mark=na/ns \
passthrough=yes
/ipv6/firewall/mangle>
add action=mark-packet chain=output comment="Neighbor Solicitation NS" \
icmp-options=135:0-255 new-packet-mark=na/ns out-interface=\
orange-wan-bridge-internet passthrough=no protocol=icmpv6
add action=mark-packet chain=output comment="Neighbor Advertisement NA" \
icmp-options=136:0-255 new-packet-mark=na/ns out-interface=\
orange-wan-bridge-internet passthrough=no protocol=icmpv6
Je diraisCode: [Sélectionner]/interface/bridge/filter >
add action=set-priority chain=output mac-protocol=arp new-priority=6 \
out-interface=vlan832-orange-internet passthrough=yes
add action=set-priority chain=output comment=NA/NS mac-protocol=ipv6 \
new-priority=6 out-interface=vlan832-orange-internet packet-mark=na/ns \
passthrough=yes
/ipv6/firewall/mangle>
add action=mark-packet chain=output comment="Neighbor Solicitation NS" \
icmp-options=135:0-255 new-packet-mark=na/ns out-interface=\
orange-wan-bridge-internet passthrough=no protocol=icmpv6
add action=mark-packet chain=output comment="Neighbor Advertisement NA" \
icmp-options=136:0-255 new-packet-mark=na/ns out-interface=\
orange-wan-bridge-internet passthrough=no protocol=icmpv6
?
...Si vous avez l'indication de comment faire pour limiter ça sur du OPNSense, je suis preneur :D merci :)
se limiter aux messages
- IPv4 : DORA + RENEW / REBIND + RELEASE
- IPv6 : SARR + RENEW / REBIND + RELEASE
respecter les cycle de vie définis dans les RFC idoines et relancer depuis le DORA / SARR en cas de perte de la connectivité montante (à tester avec ARP et ICMPv6 NS/NA) comme le fait la LiveBox
Dans la réponse DHCP, il y a une option 125 en retour dans le format avec en rouge 2 octets de code d'information : 0001000000ffffffffff
Les grandes classes de réponses sont :
- 00xx : OK vu du réseau Orange et tout doit fonctionner. Si ce n'est pas le cas le problème vient de chez vous.
- 01xx : Le modèle de box, le firmware ou votre ligne est bloquée (0102 ce qui peut arriver si le comportement de votre routeur est trop agressif ...)
- 02xx : erreur de Login ou de Mot de passe ou d'encodage
- 03xx : compte ou service probablement résilié
- 04xx : problème de règlement de la facture avec de possibles limitation de débit ou blocage.
T125 Option 125, length 17: 0.0.5.88.12.1.10.0.1.0.0.0.255.255.255.255.255Bonjour
La COS6 sert à prioriser les pkts DHCP(4/6), ARP et ICMP NS/NA entre la boxe et la BNG (premier routeur qui gère les IPs) qui gère le contexte client.
Normalement, une COS0 sur ces paquets ne devrait pas marcher, mais un bug de certain équipement le permet.
Comme vous ne pouvez pas savoir sur quel équipement vous êtes ni si vous allez rester dessus (upgrade / changement / réaménagement) je conseille fortement de passer la conf en COS6
La COS6 ne va pas plus loin que le BNG et est remplacé par une COS0 à ce point, il ne sert donc à rien de taguer tous vos paquets en COS6. De plus le trafic en COS6 est fortement limité en débit, donc là aussi, si vous pouvez limiter proprement uniquement aux paquets ci dessus, c'est nettement mieux.
La COS6 jusqu'au BNG sert à protéger le trafic d'établissement et de maintient de la connexion en cas de surcharge sur le segment client <-> BNG. Plein de cas possible.
LeVieux
Petite question,Bonne question, là je vais faire appelle à 2 ami(e)s
Pour dhcp/dhcpv6, lors des remplacements de livebox on modifie actuellement uniquement la cos (L2), mais la livebox modifie également le dscp (Cos L2+ Dscp L3).
Est-ce prévu de controler coté IP ou ça restera uniquement un controle coté L2 ?
A+
Ce matin mon openwrt obtient une ip en 172. sur une offre pro après 1 an sans coupures.
Je précise que je fais juste de l'ipv4
Je regarde l'option 90 qui n'est pas longue, j'ajuste en la rendant longue en passant par le https://jsfiddle.net/kgersen/3mnsc6wy/ pour ajouter le mot de passe associé au fti.
Et cela ne fonctionne toujours pas ! étonnant. En branchant la livebox c'est ok.
Le durcissement est effectif ou bien? only ipv4 est autorisé?
La solution https://jsfiddle.net/kgersen/3mnsc6wy/ ne suffit pas?Normalement cela devrait fonctionner
1. de temps à autre, regénerer la chaine de caractères ?Oui comme indiqué dans un poste précédent. Idéalement le changer à chaque cycle complet DHCP quand on change le TransactionID DHCP4/6 (voir RFC)
2. spoofer / copier / utiliser l'adresse mac de la livebox sur l'interface du vlan832 ?Inutile
Hello,ce script génère un salt random: https://xavier.kindwolf.org/2018-orange-dhcp/auth
ne faudrait-il pas :
1. de temps à autre, regénerer la chaine de caractères ?
2. spoofer / copier / utiliser l'adresse mac de la livebox sur l'interface du vlan832 ?
#!/bin/bash
#
#
[ -z "$2" ] && echo "usage : $0 '<fti/login>' '<passwd>'" && exit 1
login="$1" ; pass="$2"
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)
str=$(addsep $(tohex ${login})${h})
echo "# dhclient"
echo "## in ipv4 config :"
echo "send user-class \"+FSVDSL_livebox.Internet.softathome.Livebox4\";"
echo "send vendor-class-identifier \"sagem\";"
echo "send dhcp-client-identifier 01:<livebox_mac>;"
echo "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${str};"
echo "## in ipv6 config :"
echo "send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;"
echo "send dhcp-client-identifier 00:03:00:<livebox_mac>;"
echo "send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:1A:09:00:00:05:58:01:03:41:01:0D${str};"
echo
echo "# systemd-networkd"
echo "## [DHCPv4]"
str2=`echo "00:00:00:00:00:00:00:00:00:00:00:1A:09:00:00:05:58:01:03:41:01:0D${str}" | sed 's/^/\\\x/ ; s/:/\\\x/g'`
echo "ClientIdentifier=mac"
echo "SendOption=90:string:${str2}"
echo "ClientIdentifier=mac"
echo "## [DHCPv6]"
echo "DUIDType=link-layer"
echo "SendOption=11:string:${str2}"
echo "SendOption=16:string:\x00\x00\x04\x0e\x00\x05\x73\x61\x67\x65\x6d"
Merci pour l'info sur la mac address (inutile de spoofer).en effet ça ressemble à la même chose en script shell.
Perso, j'utilise ce script shell :Code: [Sélectionner]#!/bin/bash
#
#
[ -z "$2" ] && echo "usage : $0 '<fti/login>' '<passwd>'" && exit 1
login="$1" ; pass="$2"
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)
str=$(addsep $(tohex ${login})${h})
echo "# dhclient"
echo "## in ipv4 config :"
echo "send user-class \"+FSVDSL_livebox.Internet.softathome.Livebox4\";"
echo "send vendor-class-identifier \"sagem\";"
echo "send dhcp-client-identifier 01:<livebox_mac>;"
echo "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${str};"
echo "## in ipv6 config :"
echo "send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;"
echo "send dhcp-client-identifier 00:03:00:<livebox_mac>;"
echo "send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:1A:09:00:00:05:58:01:03:41:01:0D${str};"
echo
echo "# systemd-networkd"
echo "## [DHCPv4]"
str2=`echo "00:00:00:00:00:00:00:00:00:00:00:1A:09:00:00:05:58:01:03:41:01:0D${str}" | sed 's/^/\\\x/ ; s/:/\\\x/g'`
echo "ClientIdentifier=mac"
echo "SendOption=90:string:${str2}"
echo "ClientIdentifier=mac"
echo "## [DHCPv6]"
echo "DUIDType=link-layer"
echo "SendOption=11:string:${str2}"
echo "SendOption=16:string:\x00\x00\x04\x0e\x00\x05\x73\x61\x67\x65\x6d"
Je pense que cela fait la même chose ?
Bonjour
Petits rappels :
1) FFFFFFFFFFFF n'est PAS une @MAC valide ...
2) On ne met PAS deux routeurs en même temps derrière un accès ONT ...
Y'en a un qui doit sévèrement relire sa conf.
LeVieux
Toi je ne sais pas, j'ai pas les liaisons complète nom / fti / Mac / nom sur le forum lafibre.info :)
Mais si ton fti est de la forme fti/q*****4 et que tu es sur Puteaux ... Oui c'est possible. 8)
LeVieux
BonjourMerci, pas moi non plus ;)
Petits rappels :
1) FFFFFFFFFFFF n'est PAS une @MAC valide ...
2) On ne met PAS deux routeurs en même temps derrière un accès ONT ...
Y'en a un qui doit sévèrement relire sa conf.
LeVieux
option dhcp.auth code 90 = string;
option dhcp.domain-search code 119 = string;
option dhcp.sip-servers code 120 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
interface "enp1s0.832"
{
send dhcp-client-identifier 08:3E:5D:01:02:03; // ceci n'est pas la MAC de ma livebox
send vendor-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send dhcp.auth = generate("/etc/orange/auth");
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
send dhcp6.userclass 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 dhcp6.client-id 00:01:00:01:1e:bf:f5:9d:08:3E:5D:01:02:03; // ceci n'est pas non plus la MAC de ma livebox
send dhcp6.auth = generate("/etc/orange/auth");
}
Pour ma part j'ai perdu la connexion cette nuit mais je ne suis pas sur puteaux (je suis dans le 06).
Cannes ? Fait (partiellement) parti du périmètre de la nuit dernière.
LeVieux
Bonjour 8)
Je viens ici, car depuis ce matin (07/12) mon Orbi (netgear) refuse de s'authentifier sur le réseau, coupure dans la nuit...
L'ONT fonctionne bien, bref, je redémarre les boitiers, mais rien à faire, l'Orbi m'indique une erreur de connexion, et j'ai une IP en 172.19.X.X :o :o (j'ai une IP fixe normalement)
Bref appel au 3901 (c'est une ligne pro), qui ne voit rien de spécial et qui me dit as usual de brancher la box.
Bref, dans le doute, je ressors la LB4 Pro du placard, je la branche, j'attends minimum 30 minutes qu'elle fasse ses MAJ etc...
Désolé pour les techniciens qui ont du voir passer un certain nombre de requêtes de ma part (fti/z*****b) :D :D
Tout ça pour tomber ici via un autre forum, et comprendre que c'est donc normal :D
Bref, ma question est : dans l'Orbi un RBR20 (https://www.netgear.fr/support/product/rbr20.aspx), comment je peux jouer sur ces paramètres DHCP ?
Cela m'ennuie d'avoir mis mon Orbi en mode AP, et de ressortir la LB4, cela fait 2 boitiers...
Merci !
J'ai eu le même problème que toi. Fichier de config DHCP OK mais depuis hier KO.
J'ai rajouté: send dhcp-client-identifier 01:MAC ADDRESS
Et j'obtiens de nouveau une IP publique (mon ancienne même! :) ).
Bon courage.
Sais-tu si sur paris intramuros c'est deja effectif ou non ?Non pas encore.
Non pas encore.
Là c'est trêve des confiseurs jusqu'à janvier
J'ai porté plainte auprès de ma conseillère déménagement dédiée! :P (déménagement + changement règles DHCP ça fait un peu beaucoup...)
Quel incident global ? J'ai du mal à suivre.
Ta conf est OK maintenant, non? Donc tu devrais être tranquille pour les fêtes, ou j'ai raté un truc ?
Bonjour
Si vous souhaitez disposer de l'intégralité du soutien de Orange, il vous faut respecter les clause de votre CGU et utiliser le matériel Orange.
Cette opération de migration (et c'est suivi de très très près) n'a engendré aucun problème pour les clients utilisant la solution Orange de bout en bout.
Ce thread s'adresse aux aventuriers cherchant à se passer des équipements Orange pour déployer leur propre solution pour le routage. Si vous chercher à déclencher un Troll, je laisserai les MoDop décider de ce qu'il faut faire.
LeVieux
Un exemple d configuration pour un PC Linux directement connecté à l'ONT serait aussi apprécié.Bonjour Vivien
Mais si la Livebox reste le meilleur moyen de se connecter au réseau d'Orange, est-ce qu'il serait possible au moins d'avoir un mode bridge ? Ca suffirait à pas mal d'entre nous :)La on touche à la cible Marketing..
Bonjour
L'option 61 est nécessaire (RFC). Elle peut par contre contenir la MAC de ton routeur.
Il faut qu'elle soit présente
Je vais faire une synthèse de tout ce qui s'est échangé et le mettre en synthèse dans le premier post
LeVieux
serait-il possible d'aborder le DUID et la nécessité (ou pas) de débrancher la fibre (ou eteindre l'ONT) pour forcer un release ?Alors DUID et IPv6 ...
Dynamic Host Configuration Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x6ac82ac7
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: 44:d4:54:XX:XX:XX
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
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
Option: (61) Client identifier
Option: (77) User Class Information
Option: (90) Authentication
Option: (255) End
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x1eace9
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0000
Elapsed time: 0ms
Option Request
Option: Option Request (6)
Length: 8
Value: 000b001100170018
Requested Option code: Authentication (11)
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Identity Association for Prefix Delegation
Authentication
Option: Authentication (11)
Length: 70
Value: 00000000000000000000001a0900000558010341010dXXXX…
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 1a0900000558010341010dXXXX…
User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c697665626f782e496e7465726e65…
Vendor Class
Option: Vendor Class (16)
Length: 11
Value: 0000040e0005736167656d
Enterprise ID: SAGEMCOM SAS (1038)
vendor-class-data: sagem
DHCPv4 :
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: 44d454XXXXXX
l'encodage Hexa de ce qui est ci dessus : 3d 07 01 44 d4 54 XX XX XX
DHCPv6:
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
l'encodage Hexa de ce qui est ci dessus : 00 01 00 0a 00 03 00 01 44 d4 54 XX XX XX
Bonjour VivienPour la délégation ipv6 si on pouvait avoir récupérer plus qu'un /64 par exemple un /60, car pour moi c'est ce qui me dérange le plus.
Y'a plein de chose bien sur la LiveBox (test de vie montant descendant , CoS L2/L3, respect des règles ARCEP, Remote Management, 3P) qui sont très très bien.
Publier une conf DHCHP qui marche sort du mandat que j'ai et surtout c'est très incomplet par rapport à ce qui est nécessaire pour avoir un lien de qualité avec les reprises de cycle DHCP4/6 en cas de perte de connectivité (vous seriez surpris du nombre de cas totalement indépendant de Orange où cela se produit ...) et de respect de la specs DHCP (là aussi vous seriez surpris du délabrement de certain stack DHCP 4/6 ...).
Autant vous aider sur les plus gros problèmes, oui. Mais une conf qui sera incomplète par définition sauf à vous mettre l'ensemble de toutes les mécaniques à valeur ajoutées de la box, je suis pas pour.
Y'a 10 ans (aller 5 ...) la stabilité de la boxe était pas au rdv complètement et tenter de mettre autre chose me paraissait légitime. Sur les LB4 LB6, on est largement au niveau qualité. Et avec un connectivité IPv6 Full avec délégation de préfix qui commence à se faire plus que correctement.
LeVieux
Pour la délégation ipv6 si on pouvait avoir récupérer plus qu'un /64 par exemple un /60, car pour moi c'est ce qui me dérange le plus.Après relecture de la spec, on limite effectivement à un /64 par device le demandant.
Après relecture de la spec, on limite effectivement à un /64 par device le demandant.
En commençant par le dernier des dispos
Sans avoir testé l'implémentation, rien ne t'empêche d'avoir plusieurs device qui demande chacun un /64.
Tu prends un routeur pour ta DMZ, un routeur pour ton LAN clients, un routeur pour un autre.
MAIS je n'ai pas testé ce que cela fait sur une LB4/6 ....
Hello Le Vieux,:)
Mais si la Livebox reste le meilleur moyen de se connecter au réseau d'Orange, est-ce qu'il serait possible au moins d'avoir un mode bridge ? Ca suffirait à pas mal d'entre nous :)
Harold
Code: [Sélectionner]option dhcp.auth code 90 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
interface "enp1s0.832"
{
send dhcp-client-identifier 01:08:3E:5D:01:02:03; // ceci n'est pas la MAC de ma livebox
send vendor-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send dhcp.auth = generate("/etc/orange/auth");
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
send dhcp6.userclass 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 dhcp6.client-id 00:03:00:01:08:3E:5D:01:02:03; // ceci n'est pas non plus la MAC de ma livebox
send dhcp6.auth = generate("/etc/orange/auth");
}
Ne faites pas comme moi les djeuns.
Avec ISC dhclient, les formats corrects pour le client id DHCP et DHCP6 sont les suivants.
DHCP client id (option 61): 7 octets en tout. 1 octet hardware type 01 ("ethernet") + 6 octets mac address livebox
DHCP6 client id (option 1): DUID de 10 octets en tout. 2 octets DUID type 0003 ("link layer") + 2 octets hardware type 0001 ("ethernet") + 6 octets mac address livebox
A titre d'exemple, les valeurs ci-dessous corrigées:
Normal, generate ca n’existe pas dans le client isc officiel. C’est un patch écrit par un membre du forum qui rajoute la fonction.
Pour plus d’infos, ça commence là : https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg583155/#msg583155
Hello,Oui, c'est un patch de Xavier G / kindwolf ici, sources et procédure de patch ici: https://xavier.kindwolf.org/2018-orange-dhcp/
Merci pour le rappel.
Je ne connaissais pas le generate(). Ça retourne quoi ? As tu les sources ?
Merci
Mercile lien du gist sans embedding
https://gist.github.com/Strangelovian/49e1ca1acd659c7dbb5fa192fc32a7bf
Ne faites pas comme moi les djeuns.
Avec ISC dhclient, les formats corrects pour le client id DHCP et DHCP6 sont les suivants.
DHCP client id (option 61): 7 octets en tout. 1 octet hardware type 01 ("ethernet") + 6 octets mac address livebox
DHCP6 client id (option 1): DUID de 10 octets en tout. 2 octets DUID type 0003 ("link layer") + 2 octets hardware type 0001 ("ethernet") + 6 octets mac address livebox
A titre d'exemple, les valeurs ci-dessous corrigées:
le lien du gist sans embeddingCode: [Sélectionner]https://gist.github.com/Strangelovian/49e1ca1acd659c7dbb5fa192fc32a7bf
client-option "send dhcp-client-identifier 1:xxxxxxxxxxxx;"(Cette option était deja utilisée dans ma conf pour la partie décodeur TV d'ailleurs)
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox3";"
client-option "send rfc3118-auth OPTIONLONGUEDHCP;"
client-option "send dhcp-client-identifier 1:MACLIVEBOX;"
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
option 01 hex DUID
iface eth0.832 {
pd
option 16 hex XXXXXXXXXXXXXXXX
option 15 hex XXXXXXXXXXXXXXXXX
option 11 hex OPTIONLONGUEDHCP
option 1 hex 00030001MACADRESS
option dns-server
}option dhcp.auth code 90 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
interface "enp1s0.832"
{
send dhcp-client-identifier 01:XX:XX:XX:YY:YY:YY;
send vendor-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send dhcp.auth = generate("/etc/orange/auth");
send dhcp6.vendor-opts 00:00:05:58:00:06:00:0e:49:50:56:36:5f:52:45:51:55:45:53:54:45:44;
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
send dhcp6.userclass 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 dhcp6.client-id 00:03:00:01:XX:XX:XX:YY:YY:YY;
send dhcp6.auth = generate("/etc/orange/auth");
}
XX:XX:XX:YY:YY:YY --> remplacer par adresse mac liveboxCode: [Sélectionner]option dhcp.auth code 90 = string;XX:XX:XX:YY:YY:YY --> remplacer par adresse mac livebox
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
interface "enp1s0.832"
{
send dhcp-client-identifier 01:XX:XX:XX:YY:YY:YY;
send vendor-class-identifier "sagem";
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox3";
send dhcp.auth = generate("/etc/orange/auth");
send dhcp6.vendor-opts 00:00:05:58:00:06:00:0e:49:50:56:36:5f:52:45:51:55:45:53:54:45:44;
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
send dhcp6.userclass 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 dhcp6.client-id 00:03:00:01:XX:XX:XX:YY:YY:YY;
send dhcp6.auth = generate("/etc/orange/auth");
}
pour DHCPv6, J'avais oublié le Vendor-specific Information (option 17), qui est nécéssaire sinon refus et parkage au garage ipv4...
Pour résumer les options nécéssaires minimales:
IPV4 DHCP - 4 options minimales
client identifier (option 61)
vendor class identifier (option 60)
user class information (option 77)
authentifaction (option 90)
IPV6 DHCPv6 - 5 options minimales
vendor specific information (option 17): entreprise id "Orange" 4 octets 00000558 + 2 octets option code 0006 + 14 octets Option data: 495056365f524551554553544544 ("IPV6_REQUESTED")
client identifier (option 1)
user class (option 15)
vendor class (option 16)
authentication (option 11)
Avec tout ça, ipv4 + prefix ipv6 OK. Sans l'option 17: mise en isolement au parking...
Oui elle est fixe. Je m'en suis rendu compte en échouant à avoir des réponses en DHCPv6.
Hello,
J’ai raté quelque chose avec cette option 17 en ipv6 ?
C’est la première fois qu’elle est évoquée clairement, es tu certain qu’elle soit nécessaire ?
Est-elle fixe, d’après ce que je comprends ?
Merci
# dhclient
## ipv4 config file
send user-class "+FSVDSL_livebox.Internet.softathome.Livebox4";
send vendor-class-identifier "sagem";
send dhcp-client-identifier 01:<livebox_mac>;
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:2f:66:64:6b:6c:6a:6c:6b:3C:12:35:30:32:36:62:31:65:34:31:65:62:31:33:66:33:66:03:13:35:e3:8f:54:28:45:45:19:c7:64:95:10:a6:44:12:9a:e9;
## ipv6 config file
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
send dhcp-client-identifier 00:03:00:<livebox_mac>;
send dhcp6.auth 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:66:64:6b:6c:6a:6c:6b:3C:12:35:30:32:36:62:31:65:34:31:65:62:31:33:66:33:66:03:13:35:e3:8f:54:28:45:45:19:c7:64:95:10:a6:44:12:9a:e9;
#vendor-opts (option 17) seems to be required since 2022
send dhcp6.vendor-opts 00:00:05:58:00:06:00:0e:49:50:56:36:5f:52:45:51:55:45:53:54:45:44;
# systemd-networkd
## [DHCPv4]
ClientIdentifier=mac
SendOption=90:string:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1A\x09\x00\x00\x05\x58\x01\x03\x41\x01\x0D\x66\x74\x69\x2f\x66\x64\x6b\x6c\x6a\x6c\x6b\x3C\x12\x35\x30\x32\x36\x62\x31\x65\x34\x31\x65\x62\x31\x33\x66\x33\x66\x03\x13\x35\xe3\x8f\x54\x28\x45\x45\x19\xc7\x64\x95\x10\xa6\x44\x12\x9a\xe9
ClientIdentifier=mac
UserClass=FSVDSL_livebox.Internet.softathome.livebox4
## [DHCPv6]
# prefer DUIDType=link-layer if not work, reset ONT...
#DUIDRawData=00:03:00:<livebox_mac>
DUIDType=link-layer
SendOption=11:string:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1A\x09\x00\x00\x05\x58\x01\x03\x41\x01\x0D\x66\x74\x69\x2f\x66\x64\x6b\x6c\x6a\x6c\x6b\x3C\x12\x35\x30\x32\x36\x62\x31\x65\x34\x31\x65\x62\x31\x33\x66\x33\x66\x03\x13\x35\xe3\x8f\x54\x28\x45\x45\x19\xc7\x64\x95\x10\xa6\x44\x12\x9a\xe9
SendOption=16:string:\x00\x00\x04\x0e\x00\x05\x73\x61\x67\x65\x6d
# vendor-opts (option 17) seems to be required since 2022
SendOption=17:string:\x00\x00\x05\x58\x00\x06\x00\x0e\x49\x50\x56\x36\x5f\x52\x45\x51\x55\x45\x53\x54\x45\x44
# mikrotik routeros
## DHCPv4
/ip dhcp-client option
add code=60 name=vendor-class-identifier value=0x736167656d
add code=77 name=userclass value="0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834"
add code=90 name=authsend value=0x00000000000000000000001A0900000558010341010D6674692f66646b6c6a6c6b3C1235303236623165343165623133663366031335e38f5428454519c7649510a644129ae9
#clientid (option 61) is built-in
#add code=61 name=clientid value="0x01<livebox_mac_addr>"
## DHCPv6
/ipv6 dhcp-client option
add code=11 name=authsend value=0x00000000000000000000001A0900000558010341010D6674692f66646b6c6a6c6b3C1235303236623165343165623133663366031335e38f5428454519c7649510a644129ae9
add code=15 name=userclass value="0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f78340a"
add code=16 name=class-identifier value=0x0000040e0005736167656d
#vendor-opts (option 17) seems to be required since 2022
add code=17 name=vendor-opts value=0x000005580006000e495056365f524551554553544544
#clientid_duid (option 1) is built-in
#add code=1 name=clientid_duid value="0xff<livebox_mac_addr>"
Strangelovian, si ce n'est pas indiscret, es-tu dans une des zones mentionnées par levieuxatorange dans lesquelles le durcissement de la vérification des options aurait été activée?Oui Puteaux/92, impacté depuis une semaine environ.
Je n'ai pas non plus cette option, ne l'ai jamais eue et à priori en regardant dans mes (vieilles) captures, la livebox ne l'a jamais envoyée.
Bonjour
Pour ma part je suis à priori dans une zone qui a migré (j'ai perdu la connexion et je me suis rendu compte que je n'avais pas mis le bon mot de passe, depuis que je l'ai changé ça remarche), je n'ai pas l'option 17 en IPV6 mais pourtant j'ai bien de l'IPv6.
Même chose. Dans le 92 (Colombes), je ne vois pas d'option 17 en IPv6 depuis ma Livebox. Tout fonctionne bien pour le moment :
Un petit résumé en fonction des matériels/softs utilisés (manque OpenWrt que je n'utilise pas mais il y a topic dédié) :
Bien entendu les strings authentifications sont bidons ... ;DCode: [Sélectionner]# systemd-networkd
## [DHCPv4]
ClientIdentifier=mac
SendOption=90:string:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1A\x09\x00\x00\x05\x58\x01\x03\x41\x01\x0D\x66\x74\x69\x2f\x66\x64\x6b\x6c\x6a\x6c\x6b\x3C\x12\x35\x30\x32\x36\x62\x31\x65\x34\x31\x65\x62\x31\x33\x66\x33\x66\x03\x13\x35\xe3\x8f\x54\x28\x45\x45\x19\xc7\x64\x95\x10\xa6\x44\x12\x9a\xe9
ClientIdentifier=mac
UserClass=FSVDSL_livebox.Internet.softathome.livebox4
## [DHCPv6]
# prefer DUIDType=link-layer if not work, reset ONT...
#DUIDRawData=00:03:00:<livebox_mac>
DUIDType=link-layer
SendOption=11:string:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1A\x09\x00\x00\x05\x58\x01\x03\x41\x01\x0D\x66\x74\x69\x2f\x66\x64\x6b\x6c\x6a\x6c\x6b\x3C\x12\x35\x30\x32\x36\x62\x31\x65\x34\x31\x65\x62\x31\x33\x66\x33\x66\x03\x13\x35\xe3\x8f\x54\x28\x45\x45\x19\xc7\x64\x95\x10\xa6\x44\x12\x9a\xe9
SendOption=16:string:\x00\x00\x04\x0e\x00\x05\x73\x61\x67\x65\x6d
# vendor-opts (option 17) seems to be required since 2022
SendOption=17:string:\x00\x00\x05\x58\x00\x06\x00\x0e\x49\x50\x56\x36\x5f\x52\x45\x51\x55\x45\x53\x54\x45\x44
Idem à Puteaux (aussi?!) sans option 17 c'est OK.Bonjour
Pour rire un peu, quand le dhcpv6 est jugé pas bon, le back end orange donne un prefix non routé qui ressemble à s'y méprendre à un vrai préfix.Bonjour
Il est même doté d'une durée généreuse de 20 millions de secondes, soit 231 jours (autant dire que le routeur est aussi utile qu'une brique avec ça...).
Si ça vous arrive, il faut purger manuellement ce bail démoniaque >:(
Car contrairement à ipv4, ce bail dysfunctionel va se cumuler avec un bail correct, et faire dysfonctionner certains appareils en ipv6.
Logiquement, le bail le plus long est censé l'emporter.
Bonjour
La durée du bail de 231 jours est un bon indicateur de l'échec de la demande.
Même si les baux risquent d'augmenter, ils ne dépasseront jamais 1 mois
Pour retomber sur ses pieds, on avait envisager le reboot, ce qui purge les baux d'office.
L'empilement des différents baux, cela dépend tellement de vos conf et type de routeurs ...
LeVieux
J'ai du mal comprendre, moi je N'envoie PAS l'option 17 en IPv6 et j'obtiens un bail.
Bonjour
Là c'est moi qui ait du mal comprendre vos posts ::) :)
- Effectivement AUCUN besoin d'option v6 17 montante (envoyée par vous)
- Par contre si vous n'avez PAS d'option v6 17 descendante (envoyée par le réseau), là cela m'intéresse fortement car cela ne devrait pas être (si vous avez été migré en tout cas)
L'option v6 17 montante est utilisée par la LB pour demander/signifier des choses au réseau.
LeVieux
Bonjour
Là c'est moi qui ait du mal comprendre vos posts ::) :)
- Effectivement AUCUN besoin d'option v6 17 montante (envoyée par vous)
- Par contre si vous n'avez PAS d'option v6 17 descendante (envoyée par le réseau), là cela m'intéresse fortement car cela ne devrait pas être (si vous avez été migré en tout cas)
L'option v6 17 montante est utilisée par la LB pour demander/signifier des choses au réseau.
LeVieux
Par contre, si la LB envoie l'option 17 montante pour demander/signifier des choses au réseau, pourquoi ne devons-nous pas reproduire/copier ce comportement ?C'est lié au 3P et aux fonctions à valeurs ajoutées de la LB.
C'est lié au 3P et aux fonctions à valeurs ajoutées de la LB.
Pour le 1P (Internet Only) ou vous ne voulez pas les fonctions à valeurs ajoutées de la LB, pas de besoin.
Et si vous voulez ces fonctions, ressortez vos LB :) (moi je la trouve bien la LB ...)
LeVieux
Un grand merci LeVieux pour toutes ces infos partagées !
C'est vrai que la LB (6) s'améliore, il ne faut pas cracher dans la soupe. De ce que j'ai compris la délégation de prefix fonctionne mieux depuis peu.
Ce serait bien d'avoir la possibilité de mettre une route statique pour éviter le double NAT ou carrément un mode bridge... JE SAIS, C'EST MARKETING :)
Merci encore en tout cas.
Quels sont les débits observés ?
Ton routeur ne mettrait pas tout le traffic en CoS6 par hasard ? Peux-tu faire une capture de traffic entre ton routeur et l'ONT ?
# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
CLASSIFY all -- anywhere anywhere CLASSIFY set 0:1
CLASSIFY icmp -- anywhere anywhere CLASSIFY set 0:6
CLASSIFY igmp -- anywhere anywhere CLASSIFY set 0:6
CLASSIFY udp -- anywhere anywhere udp dpt:bootps CLASSIFY set 0:6
On ne peut pas faire de COS6 avec du mangle iptables.C'est une config qui fonctionne sur OpenWRT 19.07 https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/ (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/)
DHCP utilise des raw socket.
C'est une config qui fonctionne sur OpenWRT 19.07 https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/ (https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-openwrt-18-dhcp-v4v6-tv/)
Comment est construit ton vlan stp ? la partie egressEn gros mon script c'est ça :
#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
ip link set eth1.832 type vlan egress $i:$i >/dev/null
done
ip link set eth1.832 type vlan egress 1:0 >/dev/null
ip link set eth1.832 type vlan egress 0:6 >/dev/null
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
En gros mon script c'est ça :Code: [Sélectionner]#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
ip link set eth1.832 type vlan egress $i:$i >/dev/null
done
ip link set eth1.832 type vlan egress 1:0 >/dev/null
ip link set eth1.832 type vlan egress 0:6 >/dev/null
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0001
iptables -t mangle -A POSTROUTING -p icmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
Peut-être te faut-il négocier le DHCP ipv6 obligatoirement, il me semble avoir lu cela précédemment.IPv6 n'est pas obligatoire, tu peux être en IPv4 Only.
Dans quelques années, on va avoir des ressources sur l'internet qui seront IPv6 only, comme c'est le cas en Inde.Je plussois Vivien
Ne pas avoir IPv6 consiste à accepter que certains sites (et pas que des petits) soient inaccessibles.
iptables -t mangle -A POSTROUTING -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth1.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006Coucou,
Il serai interessant que nous postions les modifications faites a nos configuration sur les diferants routeurs, materiel ou logiciel, que sa soit ici, ou dans un autre thread dedié, sa pourai aider beaucoup de gens ! (dont moi ;D )
Merci bien
Coucou,
Il serai interessant que nous postions les modifications faites a nos configuration sur les diferants routeurs, materiel ou logiciel, que sa soit ici, ou dans un autre thread dedié, sa pourai aider beaucoup de gens ! (dont moi ;D )
Quel routeur/OS utilises-tu?Salut
Je plussois VivienJe donne un exemple chez Orange de service IPv6 only : l'API qui permettra d'informer (si vous donnez le consentement) un outil de test de débit comme nPerf de votre débit contractuel (savoir si vous avez une offre à 300 Mb/s, 1 Gb/s ou 2 Gb/s) ne fonctionne pas en IPv4, l'IPv6 est un pré-requis.
Pour faire marcher vos confs commencez par IPv4 Only
Mais quand cela marche finalisez aussi votre IPv6 ... Vers l'infini et au dela
Hello,
Dans les trucs bizarres, sur Mikrotik (CCR 2004 et 7.6), je n’arrive pas à avoir un bound ipv6 en cochant l’option de faire matcher le DUID avec la MAC address de l’interface. Alors que c’est ce que je faisais avec dhclient et systemd-networkd. J’ai essayé de reset l’ONT plusieurs fois et pendant plusieurs minutes mais rien à faire… bien entendu avant de changer ça, je fais un release un bail ipv6…
Moi non plus ça fonctionne pas si je coche l'option DUID-MAC
Bonjour,
J'imagine qu'il s'agit de "Use Interface DUID" comme évoqué ici : https://lafibre.info/remplacer-livebox/nouvelle-option-mikrotik-rosv7-bien-pratique-pour-orangesosh/msg914995/#msg914995. Pour obtenir un préfix IPv6 sur CHR v7.6 j'ai dû utiliser cette option après avoir bridgé mon wan832 et affecté au bridge l'adresse MAC de la livebox.
/interface bridge
add admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no name=WAN-Bridge
J'ai renouvelé la manip chez moi, où je finissais parqué en 172.x.
J'ai, dans le doute, demandé à Orange de me rappeler mes identifiants fti/ et mot de passe (c'étaient les mêmes que ceux notés à part), et j'ai renouvelé la création d'option 90/11 forgées.
IPv4 fonctionne avec l'identifiant long, mais hélas pas IPV6.
Le Log des flux DHCP montrent deux sollicitations DHCP par seconde, tout de même.
Je ne vois pas trace de retour de l'option 125 avec le status qui éclaire les réflexions.
Je ne vois pas trace de retour de l'option 125 avec le status qui éclaire les réflexions.
DHCP=: Unknown(125) = 00-00-05-58-0C-01-0A-00-01-00-00-00-FF-FF-FF-FF-FF
J'ai un ensemble d'informations à vous communiquer vous qui avez remplacé votre LB par un routeur.
Très prochainement va commencer le déploiement d'un changement dans le réseau Orange.
Bonsoir @Gnubyte,
J'ai le même code 125 que vous, en renew, et je n'ai aucun problème ni en IPv4, ni en IPv6 (release et renew ok). Selon le message de @levieuxatorange https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg988042/#msg988042 je comprends que le code erreur est dans les deux octets situés avant FF-FF-FF-FF-FF.
Bonjour lafibre, bonjour @levieuxatorange,Bonjour
Je comprends que que cela concerne les accès directs (?).
Avez-vous des informations sur des changements concernant les accès Orange Pro connectés en PPPoE avec IP fixe ?
(Routeurs autres que LB pour Internet seulement).
Merci
Cela ne concerne que les connexions en DHCPv4/v6. Aucune modification pour le PPPoE.
Par contre en terme de performance, le PPP ne pourra pas suivre la monté en débit, et il faut migrer en DHCP pour en profiter pleinement.
Toutes les LB Pro ont fait la migration vers DHCP
J'en ai bien conscience, nos usages et matériels actuels nous limitent dans tous les cas au Gb/s (que ce soit PPPoE/ONT ou LB6/DMZ).LB6 tu dois pouvoir monter à 2,5G, y'a un port 2,5 G dessus, en utilisant l'ONT interne de la LB6 pour le WAN
Bonjour
Cela ne concerne que les connexions en DHCPv4/v6. Aucune modification pour le PPPoE.
Par contre en terme de performance, le PPP ne pourra pas suivre la monté en débit, et il faut migrer en DHCP pour en profiter pleinement.
Toutes les LB Pro ont fait la migration vers DHCP
LeVieux
Par "Livebox Pro" ça sous-entend que la migration des abonnements avec option IP statique vers DHCP est prévue ?Les LB Pro font du DHCPv4 IP Statique incluse il me semble dès maintenant, avec certitude dans le cadre de la migration en cours.
Ça permettrait également d'avoir de l'IPv6, à moins que ce ne soit devenu disponible avec de l'IPv4 PPPoE.en DHCPv6 oui, qq part en 2023 je pense
Bonjour
On m'indique qu'il y a des changements de MAC à la volée en cours de session DHCP ...
Cela ne va PAS marcher :) Et là il n'y aura pas de réponse du tout car les équipements classent cela en tentative d'attaque et drop .
Vous choisissez une MAC en DEBUT de session DHCP et vous la garder tout au long jusqu'au RELEASE.
Et si vous changer de MAC trop souvent, vous aller être bloquer par l'un ou l'autre des équipements ...
LeVieux
Hello,
merci une fois de plus pour ces précisions !
D'où ma préco de spoofer une adresse mac fixe (par exemple celle de la livebox, mais pas forcément) en permanence et quelque soit l'equipement avec lequel nous faisons joujou.
En faisant cela, on reste cohérent du point de vue d'orange (et dans l'absolu), même si l'on doit changer d'équipement pour tester ou suite à une panne.
A+
Je pensais avoir lu que l’adresse MAC était obligatoirement celle de la Livebox et pas une autre, à travers les sujets de remplacement, et que ça ne fonctionnait pas sinonC'est pas obligatoirement celle de la LB, mais il vaut mieux en choisir une et la garder
Je pensais avoir lu que l’adresse MAC était obligatoirement celle de la Livebox et pas une autre, à travers les sujets de remplacement, et que ça ne fonctionnait pas sinon
J'ai bien compris que la COS 6 sur le DHCP va devenir / est deja obligatoire mais est ce aussi le cas sur l'icmp/icmpv6/arp ? ou simplement souhaitable pour la qualité de service ?J'ai bien peur que oui
Parce que la COS 6 via le bridge filter de mon RB750gr3 fait sur sacré différence sur la charge CPU comparé à aucune regle bridge (le mode fastpath saute sur le bridge).Pourquoi fait tu porter ton DHCP par le bridge et par par l'interface externe ??
J'envisage donc de faire les renew DHCP via un scheduler par ex ou sur trigger netwatch qui activerai les regles COS6 + renew le DHCP + desactive dans la foulée.Cela va être chaud de faire cela et de respecter la RFC en même temps ....
C'est faisable pour le DHCP mais pas vraiment pour les autre flux COS6.
Bonjour
J'ai fait un résumé de nos échanges dans le post 2 de ce thread
Merci de relire et me dire si vous avez besoin d'une clarification.
LeVieux
Sur mikrotik, on est obligé de passer par un bridge car c'est le seul moyen de gérer la COS sur certains packets.Au fond, c'est toujours la même raison sous-jacente.
Mikrotik appelle cela des bridge-filters.
Sous linux on peut utiliser la commande tc directement liée à une interface vlan (et non bridge).
Au fond, c'est toujours la même raison sous-jacente.
La stack ipv4 ne permet pas d'envoyer des paquets IPv4 avec src=0.0.0.0 et dst=0.0.0.0, c'est interdit.
Sauf que c'est nécéssaire pour le paquet initial DHCPv4/Bootp.
Donc ISC DHClient utilise des raw sockets pour le faire (il forge ses propres datagram IP).
Mais les raw socket contournent completement netfilter (y compris pour les chaines output / mangle), donc on ne peut pas alterer les paquets envoyés par DHClient. Avec DHCPv6 pas de problème, il n'y a pas de paquets "illégaux" à envoyer, donc une socket normale est utilisée, et on peut altérer la TOS avec netfilter.
Il faut alors passer par les vlans pour basculer tout en CS6 (y compris les facheuses trames DHCP reloues), et rebaculer tout le traffic normal en priorité standard.
Je trouve ça vraiment trop laid, donc je rebuild DHClient pour envoyer directement la bonne TOS = CS6.
Bien résumé…merci je connaissais pas systemd-networkd, je suis un dinosaure debianisant.
Tu peux aussi utiliser LD_PRELOAD et modifier la so_priority au moment du lancement dhclient, c’est peut être plus élégant… et ça évite de patcher / recompiled dhclient.
Attention aussi, dhclient est deprecated et va mourir (ou pas). J’avais migrer sur systemd-networkd, et la, tu dois utiliser un script à base de tc.
IPServiceType=
Takes one of the special values "none", "CS6", or "CS4". When "none" no IP service type is set to the packet sent from the DHCPv4 client. When "CS6" (network control) or "CS4" (realtime), the corresponding service type will be set. Defaults to "CS6".
Alors que je lance une option 1 à 0x01488F5AXXXXXX, le log indique que j'envoie 00030001 488f5aXX XXXX.Heu, en v6 tu lances une option1 0x0030001xxxxxxxxxxxx (pas 0x01xx) qui donne 000300001xxxxxxxxxxxx :)
Heu, en v6 tu lances une option1 0x0030001xxxxxxxxxxxx (pas 0x01xx) qui donne 000300001xxxxxxxxxxxx :)
Perso j'ai modifié l'Admin.MAC Address de mon bridge Wan pour que mon User Interface DUID corresponde à ce que je veux en option1. (et je l'envoie aussi donc en option 1 dans les clients options)
Je sais pas si je suis clair :p
/interface bridge
add admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no name=WAN-BridgeBonjour,
Je comprends avoir procédé comme @JcDenis : j'ai créé un bridge nommé WAN-Bridge auquel est rattaché wan832, puis j'ai changé l'adresse MAC du bridge avec :Code: [Sélectionner]/interface bridge
add admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no name=WAN-Bridge
avec XX:XX:XX:XX:XX:XX l'adresse MAC de la LiveBox. Cela a eu pour effet de changer le DUID que l'on voit dans IPv6=> DHCP Client chez moi : 0x00030001xxxxxxxxxxxx avec xxxxxxxxxxxx toujours l'adresse MAC de la livebox, enfin option 1 dans l'interface DHCPv6 Client aussi à 0x00030001xxxxxxxxxxxx.
Un expatrié aux USA voit que son réseau Français ne répond plus (https://twitter.com/TokRa14/status/1605968763039334409). La zone où est Sainte-Cécile, commune située dans le département de la Vendée en région Pays de la Loire, fait partie des zones où le durcissement du contrôle de l’option 90/11 est mis en œuvre ?
Heu, en v6 tu lances une option1 0x0030001xxxxxxxxxxxx (pas 0x01xx) qui donne 000300001xxxxxxxxxxxx :)
Perso j'ai modifié l'Admin.MAC Address de mon bridge Wan pour que mon User Interface DUID corresponde à ce que je veux en option1. (et je l'envoie aussi donc en option 1 dans les clients options)
Je sais pas si je suis clair :p
Client Identifier
Option: Client Identifier (1)
Length: 10
DUID: 00030001ffffffffffff
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: ff:ff:ff:ff:ff:ff
0001000a00030001ffffffffffff /ipv6/dhcp-client/option
add code=1 name=client-identifier value=0x00030001ffffffffffffLe clientId est envoyé automatiquement par RouterOS, que ce soit en IPV4 ou IPV6, il n'y a donc aucune option à ajouter en 4 ou en 6.
Quant à la MAC, je ne l'ai moi-même jamais touchée, et je n'ai jamais eu de problème jusqu'à présent.
En IPv4, l'option clientid est définie par défaut dans routerOS (et ne peut être supprimée) mais pour autant, ne faut-il pas la spécifier dans les options envoyées par le client DHCP ?
En Ipv6, l'option 1 est toujours envoyée indépendamment de si on coche cette option ou pas. J'avais passé à côté de l'option 'send interface duid', je pense que ça sert justement à utiliser le DUID basé sur le MAC de l'interface ce qui est bien plus simple et sûr que de modifier le DUID directement dans la nvram...
En IPv6, sauf erreur, cela correspond à la case Use interface DUID lors de la configuration de client DHCPv6.
De ce fait, en IPv6 lorsque l'option 1 est définie manuellement, n'est-il pas nécessaire de décocher la case Use interface DUID ?
Ok.
Donc il y a peut être un "bug" pour ceux qui définissent leur option 1 manuellement via les options du client DHCPv6.
Peut être que si la case Use interface DUID n'est pas cochée, le DUID présent en nvram est utilisé quoi qu'il arrive même si l'option 1 est définie dans les options ?
Attention, l'ancien système donne déjà certain code d'erreur, donc ce n'est pas un marqueur absolu
- en DHCPv6, si vous recevez une option 17, c'est que vous avez migré (même si le code retour (voir plus bas) est OK). Cette option 17 n'est PAS présente dans l'ancien système
A titre personnel je ne partage pas ton engouement pour la Livebox, c'est un point tellement crucial qu'à titre personnel j'ai quitté orange en grande partie à cause d'elle (et c'est valable pour toute les versions).
Vous confirmez que Toulouse (ceux qui y sont) et ses environs n'ont pas encore migré par rapport à l'option 17 (ipv6) et 125 (ipv4) en retour ?
tc -b - <<EOF
qdisc replace dev ${iface} \
root \
handle 1: \
prio
filter del dev ${iface}
# ARP packets emitted by kernel can be modified by netfilter but not those
# emitted by arping as it uses raw socket
filter add dev ${iface} \
parent 1: \
prio 1 \
protocol arp \
u32 \
match u8 0 0 \
action skbedit priority 0:6
# dhclient uses raw socket for DISCOVER/REQUEST
filter add dev ${iface} \
parent 1: \
prio 2 \
protocol ip \
u32 \
match ip ihl 5 0xf \
match u16 0x0000 0x1fff at 6 \
match ip protocol 17 0xff \
match ip sport 68 0xffff \
match ip dport 67 0xffff \
action skbedit priority 0:6 pipe \
action pedit pedit munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h
EOF
/interface bridge add name=bridge-WAN-ou-quel-que-soit-le-nom-du-votre admin-mac=XX:XX:XX:XX:XX:XX auto-mac=no
Bon, tout fonctionne enfin chez moi.Nice! C'était juste un souci de DUID finalement ? À tout hasard, aurais tu une capture de ce qui était envoyé par le routeur lorsque tu n'arrivais pas à obtenir de préfixe ? Juste au cas où, pour vérifier que c'est bien la différence entre MAC et DUID qui empêchait l'obtention du bail.
Oui je sais, je rêve.Hello (et bonne année)
/ipv6 dhcp-client
add add-default-route=yes dhcp-options=authsend,userclass,class-identifier dhcp-options=authsend,userclass,class-identifier interface=br-wan pool-name=pool_FT_6 rapid-commit=no \
request=prefix use-interface-duid=yes(J'ai changé d'IPv4 2 fois aujourd'hui du coup avec les release DHCP)C'est que tu es encore sur l'ancien système qui change d'IP sur Release IPv4
Entre ceux qui font du download, ceux qui avec un mec simule 20 profils différents de femme sur des forums de rencontre et ceux qui voulaient éviter les problèmes de billets qui changeaient de prix (vers le haut) quand tu revenais trop vite, on a découvert un pan complet que l'on ne soupçonnait pas ...
Cela dépend des choix réseaux. On a regardé aussi en profondeur (entre autres trucs) pour finalement rester sur le CGN + DS-LiteBonjour LeVieux,
On peut cependant diverger d'avis avec les ingé des autres opérateurs. Et la meilleurs solution pour l'un ne l'est peut être pas dans le contexte d'un autre.
J'ai vu un thread sur l'IPv6 sur le forum, une discussion des avantage de MAPE+T versus DS-LITE versus NAT444 doit se tenir là bas si vous voulez
LeVieux
Bonjour LeVieux,Hello
La cible est du DS-Lite de type "Lightweight 4over6" ?
Car le DS-Lite pur avec son aspect stateful est plutôt problématique, on a vu les déboires de nos voisins teutons avec ça et leur FritzBox. Ils ont fini par mettre en place la RFC qui permet au CPE de demander via PCP au CG-NAT d'ouvrir un port, puis aussi l'option de faire des redirections à la main qui descendent dans le CG-NAT. Il me semble que beaucoup d'ISP de ce coin sont passés sur des affectations fixes. En plus plus trop de logs.
Pour le sujet du thread, ma liste en retard au père Noël pour avoir le parfait combo LB + routeur en cascade serait la suivante:Là on touche de nouveau à la cible Mkt : je suis pas franchement certain que 99,50% de nos clients (même une partie de ceux qui sont ici ...) comprennent ce que tu viens de demander.
- Délégation plus grande que /64 possible vers le même routeur, /60 permettrait de fournir assez de vlan pour ceux qui veulent segmenter
- Avoir une petite plage IPv4 RFC1918 (une /20) routable vers un autre routeur, pour éviter de faire du NAT44 + DMZ. Je suis sûr qu'Orange peut trouver ça à bloquer dans l'IPAM. (D'ailleurs je crois qu'on peut toujours en faire sur les LB pro, :o )
Là je vois un defect (le ND tracking qui tient pas dans la durée). Si tu as plus de détails (ou d'autres sur le forum) un MP serait bien
Et pour ceux qui veulent utiliser exclusivement la LB:
- Faire fonctionner le ND tracking avec toutes les IPv6 d'un hôte afin que les ACL fonctionnent dans la durée (sur ma LB4 quand j'ouvre un port en IPv6 ça ne tient jamais longtemps)
- Avoir un package de DNS dynamique capable d'utiliser les infos du tracking pour enregistre un hôte par ligne et record DNS sur les grands noms du marché, un peu comme le package d'openWRT
Là on touche de nouveau à la cible Mkt : je suis pas franchement certain que 99,50% de nos clients (même une partie de ceux qui sont ici ...) comprennent ce que tu viens de demander.
=> Go MKT Orange GP
le second existe sur les LB pro.
La COS6 (et idéalement le pendant dscp) doit être appliqué :Merci pour toutes ces infos.
- Au DHCPv4v6 issu de la boxe
- Au ARP issu de la boxe
- A l'ICMPv6 code NS/NA issu de la boxe et à destination de l'ipv6 fe80::ba0:bab
- Rien d'autre ...
Sur LB5P, impossible d'aller plus loin que la LB au niveau du traceroute lorsque le NAT du routeur est désactivé et que seul un routage statique est mis en place. Testé avec routeur Ubiquiti et UTM WatchGuard.
Ah bah bravo. Si même ça, ça fonctionne pas... De mon côté avec Openwrt, pas de soucis, comme en témoigne le screen ci-dessous.
/ip dhcp-client add comment="Wan Orange" dhcp-options=vendor-class-identifier,user-class-information,authentication interface=<interface> script="{\
\n :if (\$bound=1) do={\
\n foreach option,value in=\$\"lease-options\" do={\
\n :if (\$option=\"125\") do={\
\n :log debug \"Found [\$value]\";\
\n :global class [:pick \$value 11];\
\n :log debug \"Extracted [\$class]\";\
\n :if (\$class=\"\\00\") do={\
\n :log info \"ISP network is OK\";\
\n };\
\n :if (\$class=\"\\01\") do={\
\n :log error \"Technical blacklist\";\
\n };\
\n :if (\$class=\"\\02\") do={\
\n :log error \"Auth or encoding failure\";\
\n };\
\n :if (\$class=\"\\03\") do={\
\n :log error \"Account or service probably terminated\";\
\n };\
\n :if (\$class=\"\\04\") do={\
\n :log error \"Invoice payment problem.\";\
\n };\
\n }\
\n }\
\n }\
\n}"Ca m'étonnerait qu'Orange prévienne pour ce genre de mises à jour, vu qu'ils ne supportent pas officiellement l'utilisation d'un autre routeur que la Livrebox. À mon sens c'est autre chose.Bonjour
sortez vos LB ... ;D
merci je connaissais pas systemd-networkd, je suis un dinosaure debianisant.Au final, systemd networkd positionne bien IP.DSCP=CS6 par défaut, mais pour la socket priority (pour la priorité 6 VLAN), j'ai ajouté la fonctionnalité moi-même: https://github.com/systemd/systemd/pull/25904
bingo https://systemd.network/systemd.network.html ! juste une config à mettre
Bien résumé…J'ai aussi appris ici https://github.com/systemd/systemd/pull/25904#issuecomment-1369999640, comme suggéré par Lennart Poetering, qu'il est possible d'utiliser eBPF afin de positionner la SO_PRIORITY, avec un noyau Linux suffisamment récent.
Tu peux aussi utiliser LD_PRELOAD et modifier la so_priority au moment du lancement dhclient, c’est peut être plus élégant… et ça évite de patcher / recompiled dhclient.
Attention aussi, dhclient est deprecated et va mourir (ou pas). J’avais migrer sur systemd-networkd, et la, tu dois utiliser un script à base de tc.
Hello,ça marche parfaitement, et même pas besoin de la mettre, par défaut c'est CS6
Au final, ça donne quoi la config pour avoir de la COS6 sur les requêtes DHCP avec systemd-networkd ?
Merci
Je ne comprends pas.https://www.man7.org/linux/man-pages/man5/systemd.network.5.html
Comment cela par défaut c’est de la COS6 ?
As-tu un exemple de config stp ?
J’utilise systemd-networkd avec un script tc pour positionner la COS6. Si je peux me passer de ce script c’est mieux…
IPServiceType=
Takes one of the special values "none", "CS6", or "CS4". When
"none" no IP service type is set to the packet sent from the
DHCPv4 client. When "CS6" (network control) or "CS4"
(realtime), the corresponding service type will be set.
Defaults to "CS6".
example un fichier /etc/systemd/network/10-ora832.network qui contient entre autres:[DHCPv4]
IPServiceType=CS6
mais c'est inutile, puisque c'est la valeur par défaut
Génial ça, je ne connaissais pas !oui il faut deux trucs, le fichier .network avec [DHCPv4] SocketPriority=6 (quand ça descendra dans les distros linux, future version 253, prendre patience...) et le fichier .netdev:
Mais cela ne modifie pas la socket priority non ?
Cette dernière doit être à 6 pour récupérer l’ip orange.
Ou bien est-ce suffisant et finalement je n’ai pas besoin de mon script à base de commande tc ? J’avais essayé et ça ne fonctionnait pas sans…
Il faut attendre la prochaine version de systemd-networkd que ton option SocketPriority soit prise en compte. C’est bien cela ?
[NetDev]
Name=ora832
Kind=vlan
[VLAN]
Id=832
EgressQOSMaps=6-6
le dernier param indique que faire de la priorité Linux pour les paquets qui sortent sur le VLAN en question
J’ai du mal à saisir la nuance et la différence entre le CS6 par défaut existant et ton patch.Tu as deux choses bien différentes, d'une part, la priority de l'entête ethernet VLAN (SocketPriority + EgressQOSMaps);
Quel est l’intérêt de la CS6 actuelle si cela ne modifie pas la socket priority utilisée par le client DHCP ?
Enfin, le param EgressQOSMaps=6-6 ne risque pas de tout marquer en COS6 sur le vlan et de perturber les perfs up/down hors DHCP ?
table ip6 mangle6 {
chain assign-orange-prio {
icmpv6 type { nd-router-solicit, nd-neighbor-solicit } ip6 dscp set cs6 meta priority set 6 counter
udp sport dhcpv6-client ip6 dscp set cs6 meta priority set 6 counter
}
}ip6 dscp set cs6Super, merci bcp pour ces explications !J'étais loin de me douter que systemd faisait autant de choses, dommage qu'il faille encore y ajouter 2/3 trucs.
Ça tombe à pique avec l’obsolescence de isc dhclient.
C’est bien la première fois que je suis impatient de tester une nouvelle version de systemd :)
As tu essayé de rajouter la vendor option comme ci dessous? J’arrive pas bien à déchiffrer le json…
J'ai mis la trace tshark sur l'interface physique (montrant vlan prio, dscp ...) si jamais qqn détecte un truc bizarre mais je pense être dans les clous.. La mac masquée est bien copiée de la LB. J'utilise un MC220L pour connecter mon router au stick.
[DHCPv6]
DUIDType=link-layer
SendVendorOption=1368:6:string:IPV6_REQUESTED
VendorClass=sagem
UserClass=FSVDSL_livebox.Internet.softathome.Livebox3
SendOption=11:string:\x00\x00\x00…Si DHCPv4 fonctionne, c’est forcément un petit soucis du payload DHCPv6, c’est un obligatoire :)J'ai eu le même problème que toi. Fichier de config DHCP OK mais depuis hier KO.
J'ai rajouté: send dhcp-client-identifier 01:MAC ADDRESS
Et j'obtiens de nouveau une IP publique (mon ancienne même! :) ).
Bon courage.
As tu essayé de rajouter la vendor option comme ci dessous? J’arrive pas bien à déchiffrer le json…Oui le vendor option (17) est bien inclu. Le problème de BBox concerne le même stick que moi VSOL V2801F et le symptôme est le même ce qui m'amène à fortement soupçonner un firewall sur le stick ou autre... Je verrai bien si j'ai la même chose avec le stick ODI..Code: [Sélectionner][DHCPv6]Si DHCPv4 fonctionne, c’est forcément un petit soucis du payload DHCPv6, c’est un obligatoire :)
DUIDType=link-layer
SendVendorOption=1368:6:string:IPV6_REQUESTED
VendorClass=sagem
UserClass=FSVDSL_livebox.Internet.softathome.Livebox3
SendOption=11:string:\x00\x00\x00…
En fait, je n'ai rien compris à ton problème BBox? Je suis confus...
Oui le vendor option (17) est bien inclu. Le problème de BBox concerne le même stick que moi VSOL V2801F et le symptôme est le même ce qui m'amène à fortement soupçonner un firewall sur le stick ou autre... Je verrai bien si j'ai la même chose avec le stick ODI..Ca serait étonnant qu'une fois le lien optique (L1 physique) établi, le modem fibre optique fasse une différence quelconque entre les trames au niveau L2 et encore moins au niveau L3.
Juste pour affiner mon analyse, savez-vous si la box (ou votre router) reçoit du traffic ipv6 (ICMP RA, NA) avant le cycle SARR ? Car moi je ne vois rien de rien passer.
Oui le vendor option (17) est bien inclu. Le problème de BBox concerne le même stick que moi VSOL V2801F et le symptôme est le même ce qui m'amène à fortement soupçonner un firewall sur le stick ou autre...Quelque chose du genre. L'IPv6 orange n'a jamais fonctionné pour moi avec le firmware VSOL.
Chez Bouygues et SFR, un DHCP&DHCPv6-PD font le taf en 5 minutes. Bonus pour SFR où ce n’est même pas sur un VLAN, c’est ultra simple.Le fti est là pour authentifier l'abonné, sur un arbre GPON partagé entre 256(?) clients. C'est plus dur à récupérer que la MAC d'un voisin.
...
Pourquoi il n’y a que orange qui a besoin des fti encodés dans une option dhcp obscure, marquée en CoS 6 alors que les 3 autres FAI s’en moquent ? Pour décourager le bidouilleur ?
Ma question pour Orange est donc la suivante : pourquoi c’est autant galère ? Pourquoi il n’y a que orange qui a besoin des fti encodés dans une option dhcp obscure, marquée en CoS 6 alors que les 3 autres FAI s’en moquent ? Pour décourager le bidouilleur ?Bonjour
C'est vrai que dans tous les cas, c'est le bizz de l'opérateur. L'opérateur fait ce qu'il veut avec le réseau qui lui appartient, le client de son côté n'a absolument rien à dire en fait
Dans busybox udhcpc rajoute une Option 57 "Maximum DHCP message size" est-ce que ça peut etre un probleme?
Tiens c’est curieux ça !Pour les amateurs de systemd networkd client qui ne release pas en DHCP6:
Ça explique peut être pourquoi certains ont parfois du mal à ré-récupérer le prefix lors de leurs tests successifs.
Pour les amateurs de systemd networkd client qui ne release pas en DHCP6:
https://github.com/systemd/systemd/pull/26043
Attendre la release 253 de systemd quand même... https://github.com/systemd/systemd/milestone/30
Que c'est beau !
merci
setsockopt(sock, SOL_SOCKET, SO_PRIORITY, 6, sizeof(int));Hello,
Question quand on parle de CoS, DSCP, QoS et ToS je ne comprends pas exactement de quoi il s'agit et lequel on veut en niveau 6.
J'ai patché mon busybox pour faire des:Code: [Sélectionner]setsockopt(sock, SOL_SOCKET, SO_PRIORITY, 6, sizeof(int));
Mais a quoi dois-je m'attendre sur Wireshark?
J'ai l'impression que cela ne fonctionne pas :(
https://ocrete.ca/2009/07/24/when-a-man-page-lies/
https://gist.github.com/wenjianhn/5700915c16e3f7d29c1bJ'ai vu une discussion que le kernel settait les deux non ?Moi aussi je faisais cette confusion. Du coup j'ai vérifié le code source du kernel il y a quelques temps...Code: [Sélectionner]https://ocrete.ca/2009/07/24/when-a-man-page-lies/
https://gist.github.com/wenjianhn/5700915c16e3f7d29c1b
Et non, le kernel n'associe pas la socket_priority interne de Linux au champs IP.DSCP.En fait si, dans l'autre sens (IP.DSCP -> socket_priority, plus exactement, il le fait avec le champ IP.TOS, qui est l'ancêtre du DSCP et qui est au même endroit dans l'entête IP...), mais UNIQUEMENT sur les paquets routés (et donc pas sur les paquets dont l'origine est le routeur lui-même).
En fait si, dans l'autre sens (IP.DSCP -> socket_priority, plus exactement, il le fait avec le champ IP.TOS, qui est l'ancêtre du DSCP et qui est au même endroit dans l'entête IP...), mais UNIQUEMENT sur les paquets routés (et donc pas sur les paquets dont l'origine est le routeur lui-même).
Le résultat de ça est d'ailleurs que dans certains cas des paquets routés se retrouvent avec une CoS VLAN à 6 à cause de leur DSCP. C'est notamment le cas avec certains clients SSH qui positionnent leur DSCP à CS6 qui se retrouve donc mappé en CoS 6 avec pour résultat des performances catastrophiques pour les transferts de fichier over SSH ou pour les tunnels...
Les astuces suivantes vont fonctionner:
- modifier le code source pour positionner la bonne valeur IP.DSCP directement dans las paquets DHCPv4 initiaux sur la RAW socket
- altérer les paquets au niveau L2/L3 par un smart switch en amont du port WAN
Quelqu'un a déja patché UDHCPC proprement ?
Je viens de perdre ma connexion. J’avais remplacer la livebox 6 par un ont orange externe… bon je vais remettre « ce truc ».Tout ne vient pas de la migration, cela peut aussi être d'autre choses :)
J'ai posté le script tc que j'utilise dans un post précédent dans ce sujet: https://lafibre.info/remplacer-livebox/durcissement-du-controle-de-loption-9011-et-de-la-conformite-protocolaire/msg993988/#msg993988
1: tc filter add dev $iface parent 1: prio 1 protocol 0x806 u32 match u32 0 0 action skbedit priority 0:6 # arp
2: tc filter add dev $iface parent 1: prio 2 u32 match ip protocol 17 ff match ip dport 67 ffff action skbedit priority 0:6 # dhcpv4
3: tc filter add dev $iface parent 1: prio 3 protocol ipv6 u32 match ip6 protocol 17 ff match ip6 dport 547 ffff action skbedit priority 0:6 # dhcpv6
4: tc filter add dev $iface parent 1: prio 4 protocol ipv6 u32 match ip6 protocol 58 ff action skbedit priority 0:6 # icmpv6
1: tc filter add dev ${iface} parent 1: prio 1 protocol arp u32 match u8 0 0 action skbedit priority 0:6
2: tc filter add dev ${iface} parent 1: prio 2 protocol ip u32 match ip ihl 5 0xf match u16 0x0000 0x1fff at 6 match ip protocol 17 0xff match ip sport 68 0xffff match ip dport 67 0xffff action skbedit priority 0:6 pipe action pedit pedit munge ip tos set 0xc0 retain 0xfc pipe action csum ip4h
Il y a 2 fois "pedit pedit" sur TA ligne 2, c'est normal ?
NET = eth1.832
table inet firewall {
chain prio_orange {
meta nfproto ipv4 \
meta priority set 0:0 \
ip dscp set cs0
meta nfproto ipv6 \
meta priority set 0:0 \
ip6 dscp set cs0
ip6 daddr { fe80::/10, ff02::/16 } \
icmpv6 type {
nd-router-solicit,
nd-neighbor-solicit,
nd-neighbor-advert
} \
meta priority set 0:6 \
ip6 dscp set cs6
ip6 daddr { fe80::/10, ff02::/16 } \
udp sport 546 \
udp dport 547 \
meta priority set 0:6 \
ip6 dscp set cs6
}
chain mangle_postrouting {
type filter hook postrouting priority mangle
policy accept
oifname $NET \
rt ipsec missing \
jump prio_orange
}
}
Question peut-être un peu bête : est-ce que par cohérence DHCPv4/v6 vous entendez également une cohérence des adresses MAC ? Je précise...Aie !
Mon switch n'est pas capable de marquer en CoS 6 en IPv4 et IPv6 sur le même port, c'est l'un ou l'autre...
Aie !
Dans un BNG, le contexte client est unique. On essaie de le lié plutôt à un indicateur indépendant des MAC.
Mais là on est dépendant de l'implémentation fournisseur et honnêtement, je le sens pas trop la MAC différente en IPv4 et en IPv6 dans un même contexte de ligne.
Cela peut marcher, ou pas, ou changer sans prévenir n'importe quand ...
LeVieux
LeVieux, sais-tu par hasard si on peut conserver le même préfixe IPv6 si on déménage à l'intérieur d'une zone couverte par le même BNG ? Si un abonné déménage dans la même ville, par exemple ?Hello
Je suis parti d'un exemple de la manpage de pedit: https://man7.org/linux/man-pages/man8/tc-pedit.8.html
Mais ça fonctionne aussi avec un seul, c'est pareil.
Pour résumer:
Nos lignes 1 sont identiques.
Nos lignes 2 match les paquets DHCPv4, mais la mienne est plus drastique dans la sélection.
Justement il faut lire "ET" entre chaque critère. Je vérifie bien que le paquet n'a pas d'option (en-tête de 20 octets donc) ET n'est pas fragmenté (ou du moins est le 1er fragment).
Si tu ne vérifie pas ça, à l'offset 20 ("ip sport" et "ip dport") il y aura bien quelque chose, mais potentiellement pas des numéros de port.
Normalement avec des paquets DHCPv4 ça n'arrivera jamais, mais je préfère être strict.
D'ailleurs tu as oublié de vérifier le port source aussi.
Puis ma ligne 1 modifie en plus le DSCP et finalement corrige le checksum IPv4 rendu invalide par la modification du DSCP.
Ta ligne 3 match les paquets DHCPv6 et ne change que la priority, pas le DSCP.
Pour être plus rigoureux il faudrait ajouter le check du port source.
Par contre attention en IPv6, "ip6 protocol" ignore les cas où tu as un header intermédiaire, tel qu'un fragmentation header par exemple.
Bon ok pour du DHCPv6 ça ne devrait pas arriver, mais c'est bon à savoir.
Ta ligne 4 match les paquets ICMPv6 et ne change que la priority, pas le DSCP.
Attention tu match tous les paquets ICMPv6, pas que les NS/NA/RS et aussi ceux qui partent vers Internet au delà du BNG.
Même remarque aussi pour "ip6 procotol".
Mon script tc ne s'occupe pas du tout de IPv6, puisque normalement aucun programme ne devrait utiliser de raw socket pour ce protocole.
Je passe par des règles nftables exclusivement:Code: [Sélectionner]NET = eth1.832
table inet firewall {
chain prio_orange {
meta nfproto ipv4 \
meta priority set 0:0 \
ip dscp set cs0
meta nfproto ipv6 \
meta priority set 0:0 \
ip6 dscp set cs0
ip6 daddr { fe80::/10, ff02::/16 } \
icmpv6 type {
nd-router-solicit,
nd-neighbor-solicit,
nd-neighbor-advert
} \
meta priority set 0:6 \
ip6 dscp set cs6
ip6 daddr { fe80::/10, ff02::/16 } \
udp sport 546 \
udp dport 547 \
meta priority set 0:6 \
ip6 dscp set cs6
}
chain mangle_postrouting {
type filter hook postrouting priority mangle
policy accept
oifname $NET \
rt ipsec missing \
jump prio_orange
}
}
Enfin ceci dit busybox udhcpc6 utilise des raw socket pour DHCPv6, mais c'est du n'importe quoi, ça fait partie des aspects que je corrige avec mes patchs.
1: tc filter add dev ${iface} parent 1: prio 1 protocol arp u32 match u8 0 0 action skbedit priority 0:6
2: tc filter add dev ${iface} parent 1: prio 2 protocol ip u32 match ip ihl 5 0xf match u16 0x0000 0x1fff at 6 match ip protocol 17 0xff match ip sport 68 0xffff match ip dport 67 0xffff action skbedit priority 0:6 pipe action pedit pedit munge ip tos set 0xc0 retain 0xfc pipe action csum ip4h
3a: tc filter add dev $iface parent 1: prio 3 protocol ipv6 u32 match ip6 protocol 17 0xff match ip6 sport 546 0xffff match ip6 dport 547 0xffff action skbedit priority 0:6 # dhcpv6 no DSCP
3b: tc filter add dev $iface parent 1: prio 3 protocol ipv6 u32 match ip6 protocol 17 0xff match ip6 sport 546 0xffff match ip6 dport 547 0xffff action skbedit priority 0:6 pipe action pedit pedit munge ip6 tos set 0xc0 retain 0xfc # dhcpv6 DSCP
tc -b - <<EOF
qdisc replace dev ${iface} \
root \
handle 1: \
prio \
bands 2 \
priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
filter del dev ${iface}
# ARP
filter add dev ${iface} \
parent 1: \
prio 1 \
protocol arp \
u32 \
match u8 0 0 \
action skbedit priority 0:6
# DHCPv4
filter add dev ${iface} \
parent 1: \
prio 2 \
protocol ip \
u32 \
match ip ihl 5 0xf \
match u16 0x0000 0x1fff at 6 \
match ip protocol 17 0xff \
match ip sport 68 0xffff \
match ip dport 67 0xffff \
action skbedit priority 0:6 pipe \
action pedit munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h
# DHCPv6
filter add dev ${iface} \
parent 1: \
prio 3 \
protocol ipv6 \
u32 \
match ip6 dst fe00::/7 \
match ip6 protocol 17 0xff \
match ip6 sport 546 0xffff \
match ip6 dport 547 0xffff \
action skbedit priority 0:6 pipe \
action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc
# ICMPv6
filter add dev ${iface} \
parent 1: \
prio 4 \
protocol ipv6 \
u32 \
match ip6 dst fe00::/7 \
match ip6 protocol 58 0xff \
action skbedit priority 0:6 pipe \
action pedit ex munge ip6 traffic_class set 0xc0 retain 0xfc
EOF
DHCPv6 toujours KO pour moi et ce depuis longtemps :(Dernière update pour ma part, j'ai bien reçu le stick ODI et oh miracle ça marche parfaitement (IPv4, IPv6)
J'ai suivi toutes les recommandations de levieux mais rien à faire, solicit solicit solicit.
J'ai toujours eu ce problème depuis que j'ai ce SFP CarlitoxxPro v2.0 qui est pourtant 05 et avec un DHCPv4 sans aucun problème (avec systemd). Je tiens ce thread: https://lafibre.info/remplacer-bbox/rtl9601b-technicolor-afm0002tim/ qui décrit un workaround sur un stick similaire mais hélas appliquer ces commandes n'a rien changé..
J'ai acheté le stick ODI en espérant résoudre ce dernier problème..
J'ai mis la trace tshark sur l'interface physique (montrant vlan prio, dscp ...) si jamais qqn détecte un truc bizarre mais je pense être dans les clous.. La mac masquée est bien copiée de la LB. J'utilise un MC220L pour connecter mon router au stick.
Je viens de refaire un essai, j'arrive bien a setter le ToS à CS6 mais je n'arrive pas a set la CoS en prio6.
J'ai patché udhcpc pour faire un
setsockopt_SOL_SOCKET_int(fd, SO_PRIORITY, 6)
https://github.com/clementperon/busybox/commit/2948bb74e8d7ae36e5d6a73aa5f6a2f4368b9660
Mais quand je capture avec wireshark le VLAN Priority est toujours en Best Effort = 0.
Merci
eth8.832 VID: 832 REORDER_HDR: 1 dev->priv_flags: 1021
total frames received 0
total bytes received 0
Broadcast/Multicast Rcvd 0
total frames transmitted 5
total bytes transmitted 855
Device: eth8
INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
EGRESS priority mappings:
ip link set dev $iface type vlan egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7
iptables v1.8.7 (legacy): unknown option "--set-class"
Try `iptables -h' or 'iptables --help' for more information.
Edit2: le '+' = 0x2b c'est la size ::)Yep, donc pas de '+', à moins que tu ne spécifies l'option encodée en hexa directement (car ton client DHCP ne connait pas l'option Vendor Class mais te permet de passer des options arbitraires).
Bon,Je ne sais pas si cela a une incidence, mais le "L" du second livebox est normalement en majuscule (c'est ce qui est envoyé par la LB en tout cas).
Je pense avoir tout setté, CoS a 6, ToS 6, les DHCP parameter list, mais toujours pas de réponse en face :(
Quelqu'un voit ce qu'il manque à ma requete DHCP?
Edit: je vois que certain mette
"FSVDSL_livebox.Internet.softathome.livebox4" ou "FSVDSL_livebox.Internet.softathome.livebox3"
et parfois avoir un '+' devant quel est le bon User Class a utiliser ?
Edit2: le '+' = 0x2b c'est la size ::)
[...]Pourquoi ? La LB l'envoie bien.
Tu peux enlever l'option 120 (SIP servers) de la liste des options demandées, normalement.
Je ne sais pas si cela a une incidence, mais le "L" du second livebox est normalement en majuscule (c'est ce qui est envoyé par la LB en tout cas).Bonjour
root@bdx-val-rt2:~# arp -n
Address HWtype HWaddress Flags Mask Iface
10.10.199.10 ether 48:b0:2d:6c:ed:47 C eth3.199
83.195.140.1 (incomplete) eth4.832
...
Aie !Bonjour
Dans un BNG, le contexte client est unique. On essaie de le lier plutôt à un indicateur indépendant des MAC.
Mais là on est dépendant de l'implémentation fournisseur et honnêtement, je le sens pas trop la MAC différente en IPv4 et en IPv6 dans un même contexte de ligne.
Cela peut marcher, ou pas, ou changer sans prévenir n'importe quand ...
LeVieux
On a au moins l'un d'entre vous dans cette config (une MAC en IPv4 et une autre MAC en IPv6).
[...]
Et la personne qui est dans ce cas va se prendre des déconnexions régulièrement.
Ca doit être @Zeda.
Hello Messieurs,
je viens de refaire un test avec "FSVDSL_livebox.Internet.softathome.Livebox4" et "FSVDSL_livebox.Internet.softathome.Livebox3" mais toujours pas de réponse en face :(.
J'ai revérifié CoS = 6, DSCP = CS6, DHCP auth, user-class, vendor-class, request list
Je sniff l'interface eth8 avec tcpdump et je vois vraiment aucune réponse en face...
Quelqu'un aurait une idée? Je sèche :-\
J'utilise udhcpc sur un router ARM64:
https://github.com/clementperon/busybox/commits/patch_applied
Salut, Je pense que oui, ça pose soucis si tu branches l'un juste après avoir débranché l'autre ..
Je suis bloqué et je ne vois aucun debug :(
Mon précédent routeur a une mac différente et utilise la même clé DHCP Auth cela peut il poser soucis ?
config interface 'WAN_DHCP'
option proto 'dhcp'
option broadcast '1'
option vendorid 'sagem'
option reqopts '1 15 28 51 58 59 90'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834 90:chaine-longue'
option _orig_ifname 'nas1'
option _orig_bridge 'false'
option ifname 'dsl0'
option clientid '01xxxxxxxxxxxx'
option macaddr 'xx:xx:xx:xx:xx:xx'
config interface 'WAN6_DHCP'
option proto 'dhcpv6'
option defaultreqopts '0'
option sendopts '11:chaine-longue 15:FSVDSL_livebox.Internet.softathome.livebox4 16:0000040e0005736167656d'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option ifname 'dsl0'
option reqaddress 'none'
option reqprefix 'auto'
option clientid '00030001xxxxxxxxxxxx'
option macaddr 'xx:xx:xx:xx:xx:xx'
option auto '0'
Salut, Je pense que oui, ça pose soucis si tu branches l'un juste après avoir débranché l'autre ..
Le mieux serait que les 2 ait la même MAC
Tu serais dire a peu près le temps d'attente pour pouvoir prendre une nouvelle mac adresse ?Il me semble que levieux@orange l'a dit sur ce topic mais je ne sais plus où... Il me semble que c'était 7 jours, mais je t'encourage très très très fortement à vérifier.
Beaucoup plus simple pour moi, l'option 61 est généré avec la mac physique avec mon nouveau router. Ce qui n'était pas le cas avec l'ancien
Cher @LeVieuxAtOrange, expert Orange entre les experts, de Brest à Strasbourg et de Lille à Perpignan, peux tu nous dire si la mise en évidence de VLANs après la synchronisation O5 et avant la requête DHCP v4|6 constitue un facteur nécessaire, prédictif, futile ou indispensable à la bonne marche de l'authentification dhcp conforme ?Cher @GnuByte, si dans le désert hurler tu veux, hors des VLANs ta requête DHCP tu dois faire.
(Toute référence à l'Oracle Usenet, dont la prose empreinte d'un humour patent m'a régalé de longues années, n'est ni fortuite ni mal intentionnée)
Idem pour moi cette nuit à 0h30, Paris 13e.Attention, en IPv6 le signe que tu es "parqué" c'est que ta Lease c'est 231 jours ...
Ip en 172.x en ipv4, plus de connectivité .. (mais préfixe ipv6 semble bon).
routeur sous opnsense, pas eu le temps de bidouiller ce matin mais je pense qu'il me manque "juste" le mot de passe dans la requete DHCP 90 (j'espère ..)
Tu peux appeler le support orange, ils les envoient par SMS.
Bonjour
Je vais répondre en parti :
C'est lié à des choix opérateur qui vont de très haut dans le SI à très bas dans le réseau.
L'objectif est d'offrir le meilleur réseau à nos clients.
Pour cela on fait un certain nombre de choix cohérents (enfin que l'on pense cohérent ... globalement, la question de l'option 90 est un point dans le tout par exemple).
Pour savoir si Orange a le meilleur réseau, je manque cruellement de neutralité :) même si j'en suis intimement persuadé
Là je vous laisse donc dire qui à le meilleur réseau
LeVieux
Mauvaise surprise ce matin: mon NRO (Clichy-Levallois) a été migré et PAF le chien…
Je pensais pourtant être au carré, visiblement j'ai raté (au moins) un truc :'(
Bilan des courses:
- "Technical Blacklist" en IPv4
- IP parking, toujours en IPv4
- Le préfixe IPv6 semble fonctionner, lui
J'ai tout débranché pour aujourd'hui et je brancherai la Livebox ce soir pour investiguer en rentrant du bureau.
Normalement, une COS0 sur ces paquets ne devrait pas marcher, mais un bug de certain équipement le permet.
Comme vous ne pouvez pas savoir sur quel équipement vous êtes ni si vous allez rester dessus (upgrade / changement / réaménagement) je conseille fortement de passer la conf en COS6
Sur openbsd, avec isc-dhclient j'ai du purger mon ancien fichier de lease ipv6 pour retrouver un fonctionnement normal.
Ipv4&ipv6 fonctionnels a nouveau.
J'ai les configs isc-client et tcpdumps des dhcp si ca peut aider...
Problème réglé ce soir.
Voilà ce qui arrive quand on est un gros boulet (comme moi) et qu'on "oublie" d'ajouter l'option 61 au dhcp-client IPv4 :-[
Bonjour,Bonjour
Petite question, de mon côté quand je fais un release en IPv4 je perds systématiquement mon IP à la reconnexion.
Pratique pour changer d'IPv4 très facilement mais y a t-il une façon de release en retrouvant la même IPv4 à la reconnexion ?
Pour l'instant j'ai plutôt tendance à utiliser le flag -x sur dhclient qui permet de quitter le processus sans lancer de release, et de release seulement quand j'en ai besoin (changement d'IP ou gros changement de configuration). Est-ce une bonne pratique ?
Merci !
En effet, suite à un reboot ou un dhcp release il ne m'est plus possible de récupérer à tous les coups une adresse IPv6 (il semble au jugé falloir attendre au moins 1j).
[…]
Il n'y a pas de parcage, simplement le ba0bab ne se donne pas la peine de répondre !
Si quelqu'un a une idée je suis preneur. Et si LeVieux passe dans les parages ce serait top :)
Hello,
C'est pas aussi simple : le routeur fait systématiquement un Release avant de faire un ou plusieurs Sollicit.
Par ailleurs j'ai testé avec dhclient, avec les mêmes options et là ça passe, j'obtiens un prefix. Le release fonctionne aussi.
En terme de différence il y a bien quelques variantes au niveau de la macaddr et de la lladdr.
La connexion ipv4 subit aussi des coupures. En faisant un release/renew elle revient.
Bref pas top...
A+
Bonjour je pense avoir été migré ce matin. J’avais la configuration EdgeRouter internet only, IPV4 + IPV6. Plus de connexion ce matin. En action rapide ce matin avant d’aller au travail j’ai simplement décoché « Enable IPV6 support » dans le GUI de l’EdgeRouter et j’ai recupéré une IPV4. Je pense que la config coté IPV6 n’etait pas 100% au point, je doute même qu’on puisse la rendre 100% compatible avec Orange maintenant sur EdgeOS d’ailleurs ?
Bonjour,
Pareil, déconnection cette nuit vers 1h10 sur Saint Laurent du Var (06)
Sur openbsd, avec isc-dhclient j'ai du purger mon ancien fichier de lease ipv6 pour retrouver un fonctionnement normal.
Ipv4&ipv6 fonctionnels a nouveau.
J'ai les configs isc-client et tcpdumps des dhcp si ca peut aider...
Hello,Bonjour
Intéressant.
On peut pas dire que ce soit super standard (euphémisme), et ça pourrait expliquer ce que certains, dont moi, ont rencontré comme problème récemment.
Bonjour
Je suis intéressé par savoir ce qui n'est pas standard là dans tes yeux ?
De ce que j'ai vois là (je me limite à Ipv4), on a
- un cycle DORA qui est valide
- puis un RENEW qui ne l'est pas ou qui n'est pas consistant avec le DORA
Et donc une décision opérateur qui constate une inconsistance/erreur entre ce qu'un client pense avoir et ce que lui a de déconnecter le client pour resynchroniser tout.
Qu'aurais tu attendu de "standard" dans ce cas là ?
LeVieux
Re
Il apparaît que dans le cas d'un "renew", on repart grosso-modo d'un milieu de cycle.
Si Orange attend comme "renew" un RELEASE puis un DORA ou SARR complet, je ne peux pas dire qu'on soit dans un standard (ie. naïvement un routeur tiers souhaite mettre en oeuvre un workflow "renew" tel que rfc).
Cdlt.
Bonjour @LeVieux,
Déjà merci pour ta réponse sur le topic.
Si l'on s'en tient aux constats et aux RFCs :
- DHCPv4 (§4.4.5), il y a aussi la "state machine" en §4.4 : https://www.rfc-editor.org/rfc/rfc2131#section-4.4
- DHCPv6 : https://www.rfc-editor.org/rfc/rfc8415.html#section-18.2.4
Il apparaît que dans le cas d'un "renew", on repart grosso-modo d'un milieu de cycle.
Si Orange attend comme "renew" un RELEASE puis un DORA ou SARR complet, je ne peux pas dire qu'on soit dans un standard (ie. naïvement un routeur tiers souhaite mettre en oeuvre un workflow "renew" tel que rfc).
Cdlt.
Re
Là il y a incompréhension :
- en RENEW on attend un RENEW standard (enfin avec l'option 90 qui va bien ...) correspondant au DORA précédent
- le RELEASE c'est en cas de perte de connectivité (ou de reboot), avant de relancer un cycle DORA complet
Sur un RENEW standard propre, cela marche juste comme ça.
J'ai des boxe (et des routeurs de la fibre) qui ont des score à plus de 300 jours.
LeVieux
Feb 22 18:20:32 _gateway DrayTek: [IGMP] Send V2 REPORT group 224.0.0.9 to WAN1 (07:B1:81:00:03:40 => 01:00:5E:00:00:09)
Feb 22 18:20:32 _gateway DrayTek: [IGMP] Send V2 REPORT group 224.0.0.9 to WAN1 (07:B1:81:00:03:40 => 01:00:5E:00:00:09)> ip dhcpc status
=====================================
WAN1:
IF#3 DHCP Client Status:
DHCP Server IP : 80.10.234.177
WAN IP : xxx.xxx.xxx.xxx
WAN Netmask : 255.255.248.0
WAN Gateway : 86.247.168.1
Primary DNS : 80.10.246.1
Secondary DNS : 81.253.149.9
Leased Time : 604800 (7 days)
Leased Time T1 : 83315 (~ 23h)
Leased Time T2 : 483840
Leased Elapsed : 603501
Leased Elapsed T1: 82016
Leased Elapsed T2: 482541Normalement, une COS0 sur ces paquets ne devrait pas marcher, mais un bug de certain équipement le permet.
/interface ethernet switch rule
add comment=DHCPv6 dst-port=547 mac-protocol=ipv6 mirror=yes new-vlan-priority=6 ports=ether23,ether3 protocol=udp src-port=546 switch=switch1 vlan-id=832
add comment=DHCPv4 dst-port=67 mac-protocol=ip mirror=yes new-vlan-priority=6 ports=ether23,ether3 protocol=udp src-port=68 switch=switch1 vlan-id=832
Pour le reste @LeVieux, soit je spoofe la MAC Wan du routeur pour faire correspondre à l'option 61, soit l'inverse (modifier l'option 61 pour la faire correspondre à la Mac).
Je testerais ça ce we. Une approche est-elle meilleure que l'autre ?
EDIT : et pour IPv6 ?
Le problème c'est que je peux pas setter explicitement le clientId (l'option est réservée), juste l'iaid.
Merci @arnaudf et @levieuxatorange pour m'avoir mis sur la piste du pourquoi le renew ne passait pas.
En effet seul le renew est fait en unicast, et n'utilise pas les meme mécanismes que le reste de dhclient (BPF) , j'ai donc simplement ajouté une règle pf qui modifie la CoS 6 aux paquets RENEW unicast et ca fonctionne a présent!
70 octets pour l’option 90 ça me parait bien court…
Bonjour,Cette valeur de 70 est correcte. C'est ce qui est généré par le script de kgersen indiqué en page 1 avec les valeurs par défaut et c'est ce qui est est envoyé également par la LB (LB4 dans mon cas).
C'est pas bête.
Pour info j'ai moi-même une longueur similaire avec une chaîne directement repompée avec Wireshark depuis une capture Livebox 5 récente (cad décembre 2022).
Et je viens de checker avec l'outil kgersen : celui-ci génère en effet une chaîne un peu plus longue.
En synthèse (et je parle uniquement de la valeur d'auth) :
- Repompé Livebox : 118 digits hexa (mais peut être induit par le dissecteur ?)
- Outil kgersen : 126 digits hexa
8 digits hexa d'écart, donc 4 octets.
Si ça peut poser problème alors va falloir que je fasse de la spéléo pour retrouver le mdp fti :)
EDIT (en mode 'captain obvious') : en fait la longueur de la valeur générée par l'outil kgersen dépend de celle du hash entrée dans le même outil
Si on laisse la valeur exemple c'est plus long (tel que décrit plus haut dans ce post), si on met une valeur réelle de hash on retombe bien sur 118 digits hexa
A+
Elle n'est a priori pas obligatoire l'option 12.Hello
Par contre quand tu dis RENEW ou REQUEST c'est quoi la différence vu de ta fenêtre ?
"En vrai" selon RFC c'est une DHCP Request qui est attendue.
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or
RENEWING)Salut,
EDIT : j'ai rebranché la livebox et çà ne fonctionne pas mieux elle est bloqué sur Initialisation 2/3
Quand je vais sur mon espace client j'ai aussi des erreurs.
Finalement la migration est peut etre pas finie ...
Hello ! la migration semble avoir été faite du côté de Nancy cette nuit. J'avais préparé la configuration de mon openwrt depuis quelques semaines déjà, il a suffit d'un simple reboot pour que ça fonctionne !Pareil ici dans l'Est du côté de Strasbourg. Le durcissement semble en place depuis cette nuit. Je me suis retrouvé avec une IP en 172.16.x vers 4h00 du mat.
Merci.
Peut-être que le firmware de la Livebox Pro est trop ancien ? (Si j'ai bien compris, cela fait plusieurs années que tu ne l'as pas branchée)Bonjour
levieuxatorange : il y a une version minimum de firmware pour être accepté sur le réseau ?
Mais je ne connais pas les "chemins" d'upgrade, et cela peut impliquer 10+ MàJ de FirmWare dans certain cas => c'est long ....
dhcp-class-identifier "sagem",user-class "+FSVDSL_livebox.Internet.softathome.Livebox3",option-90 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:68:79:61:65:66:74:33:3C:12:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search, routers,domain-name-servers,option-90dhcp-class-identifier "sagem",user-class "+FSVDSL_livebox.Internet.softathome.Livebox4",option-90 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:68:79:61:65:66:74:33:3c:12:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX,dhcp-client-identifier 01:84:YY:YY:YY:YY:YY
subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search, routers,domain-name-servers,option-90,option-15,option-120,option-125
IPV6ia-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:1a:09:00:00:05:58:01:03:41:01:0D:66:74:69:2F:68:79:61:65:66:74:33:3c:12:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XXia-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:34,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:1a:09:00:00:05:58:01:03:41:01:0D:66:74:69:2F:68:79:61:65:66:74:33:3c:12:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX,raw-option 1 00:03:00:01:01:84:YY:YY:YY:YY:YYlong comment ?Sur une vieille vieille boxe sortie d'un cimetière j'ai du faire 4h d'upgrade entre les download, flash et reboot
Ca a tourné plus d'une heure là déja...
Sur une vieille vieille boxe sortie d'un cimetière j'ai du faire 4h d'upgrade entre les download, flash et reboot
LeVieux
La mise à jour a été faite sur toulouse et ça ne marche plus de mon côté.
Il faut dire que je n’ai pas mis le nez dedans depuis un moment...
Je suis peut être un peu bête, mais dans le script de génération de l’option 90, on doit mettre quoi en mot de passe ? Je suis sensé le trouver ou ? Avant je n’utilisais que l’identifiant en fti.
À moins que c’est un mot de passe à choisir par nous même ? Même question pour le salt et byte
nicox11> Pour l'identifiant fti et le mot de passe : tu as dû recevoir ces informations sur un courrier reçu lors de ton abonnement.
Sinon, ils peuvent éventuellement être retrouvés en branchant la LB et en utilisant l'outil "Liveboxinfo" ou en contactant le service client (bonne chance).
La chaine complète d'authentification peut être générée avec l'outil de kgersen (voir page 1).
tarteens> L'option 11, c'est pour IPv6. C'est la même chaine de caractères à envoyer que l'option 90 pour IPv4.
Commence déjà par finaliser la configuration pour retrouver une IPv4 fonctionnelle et ensuite attaquer IPv6.
de ce que je lis ici c'est qu'il faut une configuré l'IPv6.Non.
Password : dans le vieux courrier de prise d'abonnement Orange (voir Wanadoo pour les plus vieux d'entre vous ...)
Ou bien remplir les infos de contact sur Orange.fr et demander un nouveau MdP envoyé par SMS ..
Salt / Byte : Read T Fabuloust Post2 de ce Thread
LeVieux
Justement, je ne sais pas comment m'y prendre pour avoir un IPv4 fonctionnel, et de ce que je lis ici c'est qu'il faut une configuré l'IPv6.
Sinon je ne voie absolument pas quoi faire pour que tout refonctionne comment avant :(
Dans mon cas j'ai simplement du :
- ajouter le DUID (dhcp-client-identifier avec la mac adress de ma livebox en 04:
- regenerer le couple fti/XXXXX + mot de passe avec l'outil en javascript
Comme toi je n'avais plus le mot de passe du compte fti/ mais il trainait dans ma config opnsense / pfsense à l'époque du pppoe
Pour Mikrotik çà semble ici : https://lafibre.info/remplacer-livebox/guide-de-connexion-fibre-directement-sur-un-routeur-voire-meme-en-2gbps/msg807104/#msg807104
J'ai besoin d'un petit coup de main.Après avoir effectué une trace tcpdump, j'ai bien aussi ce code "000100000000000000000018" en retour option 17 sur IPv6, cela semble OK. IPv6 ok pour ma part.
J'ai rebranché la livebox puis récupérer des informations, puis j'ai pu récupérer mon ipv4 avec le mikrotik.
Par contre, je n'ai toujours pas d'IPv6.
Lorsque je regarde le code de retour de DHCPv6 (option 17), je vois la valeur "000100000000000000000018".
Pour moi ça veut dire que tout va bien pourtant...
Est-ce possible que ce soit du à un timer qui doit expirer ou quelque chose ?
J'aimerai éviter de devoir patienter 3 ou 7 jours que le bail expire pour récupérer l'IPv6. Une idée sur ce que je peux faire ?
promis je rebranche la LBv4 ce soir quand c plus calme.
c'est clairement nul, tu as un pb de livebox, le SAV t'en file une en moins d'une heure, certes, mais il lui faudra 4h pour se remettre à niveau...Normalement non, les LB du SAV ne "sortent pas du cimetière" :)
Normalement non, les LB du SAV ne "sortent pas du cimetière" :)
Elles peuvent avoir une ou deux versions de retard, mais en général cela prend 15 minutes pour la MàJ complète (en comptant les 2 reboot)..
LeVieux
Je n'ai pas suivi les 39 pages mais si je comprends bien le premier post, l'accès en PPPoE ça va bientôt se terminer ?Bonjour
J'ai un routeur qui se connecte à l'ONT par ce biais. RAS pour le moment mais pour combien de temps ?
Bonjour
Non pas de date prévue pour la fin du PPPoE => un routeur faisant du PPPoE marchera. A ce jour pas de roadmap de décommissionnement du PPPoE
Par contre l'optimal est et restera le DHCP là où c'est possible
LeVieux
Ca fait 3 mois je retiens mon souffle, je suis tout bleu, toujours pas migré dans le 75 on dirait :)
Sur une utilisation basique, qu'apporte la connexion en DHCP par rapport à PPPoE ?Une MTU un peu plus élevée (MTU de 1492 en PPPoE et 1500 avec DHCP) et un débit 0,6% plus rapide lié aux 8 octets supplémentaires sur chaque paquet et les paquets un peu plus petits ?
Une MTU un peu plus élevée (MTU de 1492 en PPPoE et 1500 avec DHCP) et un débit 0,6% plus rapide lié aux 8 octets supplémentaires sur chaque paquet et les paquets un peu plus petits ?Ipv6
Re
Tu as raison, ta lecture de la RFC, j'ai retrouvé un RENEW de prod :
- pas d'option 50
- pas d'option 54
Je me replonge dans ta trace
LeVieux.
A mon sens cela vient du dissecteur dhcpv4 (si tu regardes dhcpv6 le décodage est différent).
Une MTU un peu plus élevée (MTU de 1492 en PPPoE et 1500 avec DHCP) et un débit 0,6% plus rapide lié aux 8 octets supplémentaires sur chaque paquet et les paquets un peu plus petits ?
Je m'occupe de deux sites dans les environs de Toulouse, tous les deux en contrat Sosh et je confirme qu'aucun des deux n'a été migré (pas d'option 17 en retour en DHCPv6, la chaîne d'auth sans le mot de passe fonctionne encore, etc...)
Je profite justement des vacances pour mettre les choses "au carré" et éviter de perdre la connexion.
Conformément aux recommandations de LeVieux, en plus des options adéquates dans les clients DHCPv4/DHCPv6, j'ai implémenté un mécanisme de vérification de lien montant en utilisant les outils arping pour IPv4 et ndisc6 pour IPv6.
Cependant, j'ai pu constater qu'en cas de saturation de débit, certaines vérifications IPv4 échouaient mais pas celles en IPv6.
J'avais bien pensé à tagger les paquets ARP et NS émis en COS6, via netfilter.
Cependant, arping utilise des raw sockets, donc même problème qu'avec dhclient en IPv4, pas de netfilter possible.
J'ai donc changé de méthode pour passer par une solution basée sur un script tc qui tagge tous les paquets ARP, qu'ils soient émis par le kernel ou arping.
Depuis, tous les tests IPv4 et IPv6 passent sans problème, quelque soit l'état de saturation de la ligne.
Tout ça pour confirmer que, même si vous êtes dans une zone où "ça marche sans", il vaut mieux vraiment appliquer la COS6.
Par ailleurs, pour le DHCPv4, j'ai trouvé un moyen de modifier aussi le DSCP via tc.
Je sais que ce qui importe le plus, c'est la COS6, mais d'après LeVieux c'est mieux si le DSCP est en phase avec la COS.
De plus, la LB le fait, donc moi aussi.
Je ne crois pas avoir vu cette astuce ailleurs, donc je la poste ici, si ça peut servir...Code: [Sélectionner]tc -b - <<EOF
qdisc replace dev ${iface} \
root \
handle 1: \
prio
filter del dev ${iface}
# ARP packets emitted by kernel can be modified by netfilter but not those
# emitted by arping as it uses raw socket
filter add dev ${iface} \
parent 1: \
prio 1 \
protocol arp \
u32 \
match u8 0 0 \
action skbedit priority 0:6
# dhclient uses raw socket for DISCOVER/REQUEST
filter add dev ${iface} \
parent 1: \
prio 2 \
protocol ip \
u32 \
match ip ihl 5 0xf \
match u16 0x0000 0x1fff at 6 \
match ip protocol 17 0xff \
match ip sport 68 0xffff \
match ip dport 67 0xffff \
action skbedit priority 0:6 pipe \
action pedit munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h
EOF
(Attention, si vous êtes sur un kernel < 5.1, il faut enlever le "protocol ip" du 2ème filter)
Avec cette astuce, il est possible de modifier non seulement la priorité COS6, mais aussi la priorité IP DSCP de n'importe quel paquet, même ceux issus d'une raw socket, sans aucun patch, sans LD_PRELOAD, ni rien compiler.
Frame 1: 440 bytes on wire (3520 bits), 440 bytes captured (3520 bits) on interface 0
Interface id: 0 (enp7s0.832)
Interface name: enp7s0.832
Encapsulation type: Ethernet (1)
Arrival Time: Mar 5, 2023 14:21:10.537803259 CET
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1678022470.537803259 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 440 bytes (3520 bits)
Capture Length: 440 bytes (3520 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:bootp]
Ethernet II, Src: Compulab_1f:65:e0 (00:01:c0:1f:65:e0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Compulab_1f:65:e0 (00:01:c0:1f:65:e0)
Address: Compulab_1f:65:e0 (00:01:c0:1f:65:e0)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
0001 00.. = Differentiated Services Codepoint: Unknown (4)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 426
Identification: 0x0000 (0)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (17)
Header checksum: 0x3934 [validation disabled]
[Header checksum status: Unverified]
Source: 0.0.0.0
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Source Port: 68
Destination Port: 67
Length: 406
Checksum: 0x6faa [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x9b9da747
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
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: Compulab_1f:65:e0 (00:01:c0:1f:65:e0)
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: 90.92.94.22
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: (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: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: IngramMi_1b:59:35 (44:a6:1e:1b:59:35)
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
User Class Length: 43
User Class Data: 46535644534c5f6c697665626f782e496e7465726e65742e...
Option: (255) End
Option End: 255
Frame 1: 440 bytes on wire (3520 bits), 440 bytes captured (3520 bits) on interface 0
Interface id: 0 (enp7s0.832)
Interface name: enp7s0.832
Encapsulation type: Ethernet (1)
Arrival Time: Mar 5, 2023 14:20:43.401813171 CET
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1678022443.401813171 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 440 bytes (3520 bits)
Capture Length: 440 bytes (3520 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:bootp]
Ethernet II, Src: Compulab_1f:65:e0 (00:01:c0:1f:65:e0), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: Compulab_1f:65:e0 (00:01:c0:1f:65:e0)
Address: Compulab_1f:65:e0 (00:01:c0:1f:65:e0)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 426
Identification: 0x0000 (0)
Flags: 0x0000
0... .... .... .... = Reserved bit: Not set
.0.. .... .... .... = Don't fragment: Not set
..0. .... .... .... = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (17)
Header checksum: 0x3934 [validation disabled]
[Header checksum status: Unverified]
Source: 0.0.0.0
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Source Port: 68
Destination Port: 67
Length: 406
Checksum: 0x9569 [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xa3b17974
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
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: Compulab_1f:65:e0 (00:01:c0:1f:65:e0)
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: 90.92.94.22
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: (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: (60) Vendor class identifier
Length: 5
Vendor class identifier: sagem
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: IngramMi_1b:59:35 (44:a6:1e:1b:59:35)
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
User Class Length: 43
User Class Data: 46535644534c5f6c697665626f782e496e7465726e65742e...
Option: (255) End
Option End: 255
Je constate le même phénomène sur mes captures et toutes celles que j'ai pu voir postées dans le forum. Surtout sur une Livebox "genuine" on observe la même chose.
A mon sens cela vient du dissecteur dhcpv4 (si tu regardes dhcpv6 le décodage est différent).
Sur CRS, il faut passer une switch rule :
/interface ethernet switch rule
add comment="Orange COS dhcpv4" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS dhcpv6" dst-port=547 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1 vlan-id=832
add comment="Orange COS icmpv4" mac-protocol=ip new-vlan-priority=6 ports=sfp1.router protocol=icmp switch=switch1 vlan-id=832
add comment="Orange COS icmpv6" mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=icmp switch=switch1 vlan-id=832
pour ARP, j'hésite à préciser le VLAN-ID...
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1 vlan-id=832
OU
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1
J'ai tenté d'appliquer ça @cyayon sur mon CRS305, mais les paquets DHCP ne semble pas prendre en compte cela quand je fais une capture depuis le RB5009. J'obtiens une DSCP: CS0 dans les 2 sens.Hello,
As tu une configuration plus à jour ? Quelqu'un a t'il une autre façon de faire ? Si vous avez une idée ou un morceau de configuration, je suis preneur. Merci !
1- je suis en kernel 4.9 (debian stretch) et lorsque j'utilise tes 2 lignes d'action supplémentaires pour positionner la priorité DSCP à 6 dans le script trafficcontrol, je n'obtiens plus de réponse du serveur DHCP Orange donc je suppose que cette modif "casse" la requête DHCP.
sans les actions de prio DSCP, cette frame ci-dessous reçoit une réponse d'orange:
...
As tu une idée de ce qui peut poser problème ? Le checksum pourrait-il être incorrectement calculé ?
2- je suis preneur des mécanismes de vérification de lien montant utilisant les outils arping pour IPv4 et ndisc6 pour IPv6 que tu as implémentés, si tu es d'accord pour les partager, sachant que je souhaite faire la même chose, et même si tes scripts ne sont pas exécutables en l'état chez moi, c'est toujours plus facile de partir d'une base solide que de tout réinventer.
Hello,
Ces règles ne modifient pas le DSCP (champ ip), mais la priorité vlan (champ Ethernet 802.1p)
Edit : pour le dscp il faudrait regarder côté firewall/mangle.
la règle ICMPv6 tag tout le protocole et pas seulement les codes NS/NA et RS.Bonjour
Le rollout a l'air très lent... quelqu'un sait-il à quelle maille c'est déployé ? Ville par ville ? BNG par BNG ?Bonjour
Pourtant si je reprend le topic de levieuxatorange, je ne vois pas de CoS 6 en ICMPv4, pourtant présente dans les règles cités dans mon précédent topic et la règle ICMPv6 tag tout le protocole et pas seulement les codes NS/NA et RS.Tu as raison pour ICMPv4, c'est pas listé dans le post de @LeVieux, tu peux sans doute de ne pas le mettre. Mais je doute que ça casse quelque chose.
/interface ethernet switch rule
add comment="Orange COS dhcpv4" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS dhcpv6" dst-port=547 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS icmpv6 DST (fe00::/7 = fe80::/10 + ff02::/16)" dst-address6=fe00::/7 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=icmp switch=switch1 vlan-id=832
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1 vlan-id=832
Sur mikrotik, j'utilse ca pour modifier la COS :Ok, cela c'est bon.
l'ICMPv6 est certes modifié sans distinction sur les type de packets MAIS uniquement ceux à destination de fe00::/7 (= fe80::/10 + ff02::/16).
C'est pas optimum mais je pense que c'est acceptable.
Ok, cela c'est bon.
Normalement le trafic en interface local n'est que pour l'établissement et maintien de session
LeVieux
Sur mikrotik, j'utilse ca pour modifier la COS :Code: [Sélectionner]/interface ethernet switch rule
add comment="Orange COS dhcpv4" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS dhcpv6" dst-port=547 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS icmpv6 DST (fe00::/7 = fe80::/10 + ff02::/16)" dst-address6=fe00::/7 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=icmp switch=switch1 vlan-id=832
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1 vlan-id=832
l'ICMPv6 est certes modifié sans distinction sur les type de packets MAIS uniquement ceux à destination de fe00::/7 (= fe80::/10 + ff02::/16).
C'est pas optimum mais je pense que c'est acceptable.
[admin@MikroTik] /interface ethernet switch rule> add comment="Orange COS dhcpv4" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=switch1-cpu protocol=udp switch=switch1 vlan-id=832
failure: not supported for this switch
[admin@MikroTik] /interface ethernet switch rule>
Sur mikrotik, j'utilse ca pour modifier la COS :Code: [Sélectionner]/interface ethernet switch rule
add comment="Orange COS dhcpv4" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS dhcpv6" dst-port=547 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=udp switch=switch1 vlan-id=832
add comment="Orange COS icmpv6 DST (fe00::/7 = fe80::/10 + ff02::/16)" dst-address6=fe00::/7 mac-protocol=ipv6 new-vlan-priority=6 ports=sfp1.router protocol=icmp switch=switch1 vlan-id=832
add comment="Orange COS arp" mac-protocol=arp new-vlan-priority=6 ports=sfp1.router switch=switch1 vlan-id=832
l'ICMPv6 est certes modifié sans distinction sur les type de packets MAIS uniquement ceux à destination de fe00::/7 (= fe80::/10 + ff02::/16).
C'est pas optimum mais je pense que c'est acceptable.
Merci @cyayon pour ton aide
Problème, je crois que le modéle de mon Mikrotik ne supporte pas les "cpu switch rule"
https://i.mt.lv/cdn/product_files/RB760iGS-esw3_190600.png
C'est aussi pour cela que j'applique la Cos6 via un brige sur le Vlan832
En revanche, actullement, je ne fais rien pour ce qui est de l'icmp et l'arp
Peut être je pourrais appliquer cela via le bridge ?Code: [Sélectionner][admin@MikroTik] /interface ethernet switch rule> add comment="Orange COS dhcpv4" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=switch1-cpu protocol=udp switch=switch1 vlan-id=832
failure: not supported for this switch
[admin@MikroTik] /interface ethernet switch rule>
/interface bridge filter
add action=set-priority chain=output comment="orange1 COS6_DHCP4" disabled=yes dst-port=67 ip-protocol=udp log=yes log-prefix="orange1 COS6_DHCP4" mac-protocol=ip new-priority=6 out-interface=vlan832-orange1 passthrough=yes
add action=set-priority chain=output comment="orange1 COS6_DHCP6" disabled=yes dst-port=547 ip-protocol=udp log=yes log-prefix="orange1 COS6_DHCP6" mac-protocol=ipv6 new-priority=6 out-interface=vlan832-orange1 passthrough=yes
add action=set-priority chain=output comment="orange1 COS6_ICMP6" disabled=yes ip-protocol=icmpv6 log-prefix="orange1 COS6_ICMP6" mac-protocol=ipv6 new-priority=6 out-interface=vlan832-orange1 passthrough=yes
add action=set-priority chain=output comment="orange1 COS6_ARP" disabled=yes log=yes log-prefix="orange1 COS6_ARP" mac-protocol=arp new-priority=6 out-interface=vlan832-orange1 passthrough=yes
/ipv6 firewall mangle
add action=mark-packet chain=output comment="Neighbor Solicitation NS" icmp-options=135:0-255 new-packet-mark=na/ns out-interface=br-wan passthrough=no protocol=icmpv6
add action=mark-packet chain=output comment="Neighbor Advertisement NA" icmp-options=136:0-255 new-packet-mark=na/ns out-interface=br-wan passthrough=no protocol=icmpv6/ipv6 firewall filter
add action=accept chain=input dst-port=546 in-interface=br-wan protocol=udp src-address=fe80::ba0:bab/128
/ipv6 firewall mangle
add action=change-dscp chain=output comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - DHCPv6 - DSCP to 6" dst-port=547 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=udp src-port=546
/ipv6 firewall mangle
add action=set-priority chain=output comment="Orange - icmpv6 (type 133 - RS) - COS to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=set-priority chain=output comment="Orange - icmpv6 (type 136 - NA) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=set-priority chain=output comment="Orange - icmpv6 (type 135 - NS) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=set-priority chain=output comment="Orange - DHCPv6 - COS to 6" dst-port=547 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=udp src-port=546
Pour changer le DSCP :Je vois que tu utilises la chaine mangle postrouting, qui du coup est aussi appliquée aux paquets routés. Le changement de DSCP n'a à priori besoin d'être fait que pour les paquets dont l'origine est le routeur, donc pourquoi ne pas utiliser la chain mangle output ?
Je vois que tu utilises la chaine mangle postrouting, qui du coup est aussi appliquée aux paquets routés. Le changement de DSCP n'a à priori besoin d'être fait que pour les paquets dont l'origine est le routeur, donc pourquoi ne pas utiliser la chain mangle output ?
En pratique ça n'aura pas vraiment d'importance vu la restriction sur la dst-address qui est link local ou multicast (et qui va donc s'appliquer aux paquets générés par le routeur uniquement), mais comme je suis en train de configurer mon CCR2004 je me posais la question.
Déjà pour commencer je vois un soucis:
Ton adresse MAC dans l'en-tête Ethernet est cohérente avec celle du header BOOTP (apparemment celle de ton routeur) mais pas avec la MAC de l'option 61 (apparemment celle de ta LB).
Cette incohérence est problématique, tu devrais changer pour avec la même MAC partout.
(OK même la 1ère trame qui fonctionne a ce défaut, mais quand même il vaut mieux corriger).
Ensuite, tu devrais faire la capture sur l'interface physique (enp7s0) et pas l'interface virtuelle VLAN (enp7s0.832), ça permet de voir si la COS est bien définie.
Si tu as un .pcap à m'envoyer ça m'intéresse.
Et d'ailleurs quelle conf as-tu faise exactement pour tc ? Ton kernel est un peu ancien, certains comportements peuvent changer par rapport aux derniers en date.
J'ai pushé ma config ici : https://gitlab.com/herveboisse/dhcp-orange
Je ne sais pas si mon implémentation peut être considérée comme une base solide, mais je peux en tout cas témoigner d'un cas que j'ai rencontré il y a environ un mois.
Un après-midi, la diode Fibre de l'ONT Huawei est passée au rouge et la connexion a été coupée, suivi de la réception d'un SMS de notification d'incident sur le mobile du titulaire de la ligne.
Au bout d'une heure environ le problème a été réglé.
Avec cette configuration en place, les clients DHCP v4 et v6 ont été relancés automatiquement et tout est retombé en marche sans aucune intervention de ma part.
ip link set dev enp7s0.832 type vlan egress-qos-map 0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0
tc qdisc replace dev enp7s0.832 root handle 1: prio \
bands 2 \
priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc filter del dev enp7s0.832
# DHCPv4 (raw sockets, do not specify "protocol ip")
tc filter add dev enp7s0.832 parent 1: prio 2 u32 \
match ip ihl 5 0xf \
match u16 0x0000 0x1fff at 6 \
match ip protocol 17 0xff \
match ip sport 68 0xffff \
match ip dport 67 0xffff \
action skbedit priority 0:6 pipe \
action pedit munge ip tos set 0xc0 retain 0xfc pipe \
action csum ip4h
après je n'ai pas testé, j'utilise uniquement les switch rules sur un CRS305. tiens-nous au courant...Je fais également toute la CoS sur un CRS305, donc ça serait uniquement pour le DSCP. Comme ça marche sans je pense que de toute façon je vais créer les règles et les désactiver pour pouvoir les activer rapidement si ça devient obligatoire.
Je fais également toute la CoS sur un CRS305, donc ça serait uniquement pour le DSCP. Comme ça marche sans je pense que de toute façon je vais créer les règles et les désactiver pour pouvoir les activer rapidement si ça devient obligatoire.
Je fais également toute la CoS sur un CRS305, donc ça serait uniquement pour le DSCP. Comme ça marche sans je pense que de toute façon je vais créer les règles et les désactiver pour pouvoir les activer rapidement si ça devient obligatoire.
J'ai fais de même pour le coup.
Sinon dans vos règles, je vois souvent "out-interface=vlan832-wan". On parle de l'interface VLAN ou du bridge ?
J'ai un bridge (br-wan) dans lequel j'ai mon interface vlan832, sur lequel j'applique les règles et j'ai beaucoup de mal à atteindre 2Gb/s, c'est lié ?
Merci pour les informations @breizyann.Si je ne me trompe pas, les CRS3xx sont capable de régler la COS avec des switch rules, mais pas la DSCP.
Ayant un CRS305 juste devant appliquant les règles proposées par @cyayon, je n’ai pas de bridge filter sur mon RB5009.
Le bridge est donc inutile et peut être supprimé, me permettant d’obtenir un meilleur débit, si je comprends bien ?
@cyayon et @zoc c’est ce que vous faites ?
C’est le cas, je règle la CoS avec des switch rules sur mon CRS305.Mon expérience personnelle, sur un CCR2004:
Les règles firewall mangle permettant de modifier le DSCP ne peuvent-elles pas s’appliquer sur l’interface vlan 832 côté routeur (dans min cas sur le RB5009) ?
C’est le cas, je règle la CoS avec des switch rules sur mon CRS305.
Les règles firewall mangle permettant de modifier le DSCP ne peuvent-elles pas s’appliquer sur l’interface vlan 832 côté routeur (dans min cas sur le RB5009) ?
Impossible de récupérer Ipv4 après reboot du routeur (ma config ci-dessous)Tu n'as pas de réponse, ou tu obtiens une IP parking ?
Tu n'as pas de réponse, ou tu obtiens une IP parking ?
Dans le second cas, vérifie la valeur de l'option 125 en DHCP4 (option 17 en v6)
IP de parking pour les deux (ipv4 et ipv6) mais ipv6 je peux la récupérer un faisant juste un release avec le bouton RELEASE sur le client dhcpv6 de la winbox.
Je fais la même chose sur le client dhcp (ipv4) mais ça me retourne toujours une ip de parking: 172.16.x.x
/ip dhcp-client add comment="Orange public IPv4" dhcp-options=vendor-class,user-class,authentication,clientid interface=<TON_INTERFACE> script="{\
\n :if (\$bound=1) do={\
\n foreach option,value in=\$\"lease-options\" do={\
\n :if (\$option=\"125\") do={\
\n :log debug \"IPv4: Found [\$value]\";\
\n :global class [:pick \$value 11];\
\n :log debug \"Extracted [\$class]\";\
\n :if (\$class=\"\\00\") do={\
\n :log info \"IPv4: ISP network is OK\";\
\n };\
\n :if (\$class=\"\\01\") do={\
\n :log error \"IPv4: Technical blacklist\";\
\n };\
\n :if (\$class=\"\\02\") do={\
\n :log error \"IPv4: Auth or encoding failure\";\
\n };\
\n :if (\$class=\"\\03\") do={\
\n :log error \"IPv4: Account or service probably terminated\";\
\n };\
\n :if (\$class=\"\\04\") do={\
\n :log error \"IPv4: Invoice payment problem.\";\
\n };\
\n :if (\$class=\"\\99\") do={\
\n :log error \"IPv4: CoS & DSCP issue.\";\
\n };\
\n }\
\n }\
\n }\
\n}"Et DHCPv6:/ipv6 dhcp-client add add-default-route=yes comment="Orange public IPv6 prefix delegation" dhcp-options=authentication,user-class,vendor-class dhcp-options=authentication,user-class,vendor-class interface=<TON_INTERFACE> pool-name=pool-v6orange rapid-commit=no request=prefix script="{\
\n :if (\$\"pd-valid\"=1) do={\
\n foreach option,value in=\$options do={\
\n :if (\$option=\"17\") do={\
\n :log debug \"IPv6: Found [\$value]\";\
\n :global class [:pick \$value 11];\
\n :log debug \"Extracted [\$class]\";\
\n :if (\$class=\"\\00\") do={\
\n :log info \"IPv6: ISP network is OK\";\
\n };\
\n :if (\$class=\"\\01\") do={\
\n :log error \"IPv6: Technical blacklist\";\
\n };\
\n :if (\$class=\"\\02\") do={\
\n :log error \"IPv6: Auth or encoding failure\";\
\n };\
\n :if (\$class=\"\\03\") do={\
\n :log error \"IPv6: Account or service probably terminated\";\
\n };\
\n :if (\$class=\"\\04\") do={\
\n :log error \"IPv6: Invoice payment problem.\";\
\n };\
\n :if (\$class=\"\\99\") do={\
\n :log error \"IPv6: CoS & DSCP issue.\";\
\n };\
\n }\
\n }\
\n }\
\n}" use-interface-duid=yes use-peer-dns=no
J'utilise un script sur mes dhcp-client pour vérifier la valeur des option 125 et 17.
IP de parking pour les deux (ipv4 et ipv6) mais ipv6 je peux la récupérer un faisant juste un release avec le bouton RELEASE sur le client dhcpv6 de la winbox.Je n'ai répondu qu'à une partie de la question, désolé.
Je fais la même chose sur le client dhcp (ipv4) mais ça me retourne toujours une ip de parking: 172.16.x.x
Analyze de l'option 125 DHCP4 => j'y ai pensé mais comment je fais sachant que la fibre rentre directement sur le port SFP du routeur.
Peut 'ton dupliquer le port SFP vers un port ethernet afin d'analyser avec wireshark par exemple?
/ipv6/firewall/mangle> print
Flags: X - disabled, I - invalid; D - dynamic
0 ;;; Neighbor Solicitation NS
chain=output action=mark-packet new-packet-mark=na/ns passthrough=no protocol=icmpv6 out-interface=orange-wan-bridge-internet icmp-options=135:0-255 log=no log-prefix=""
1 ;;; Neighbor Advertisement NA
chain=output action=mark-packet new-packet-mark=na/ns passthrough=no protocol=icmpv6 out-interface=orange-wan-bridge-internet icmp-options=136:0-255 log=no log-prefix=""
2 ;;; Router Solicitation
chain=output action=mark-packet new-packet-mark=na/ns passthrough=no protocol=icmpv6 out-interface=orange-wan-bridge-internet icmp-options=133:0-255 log=no log-prefix=""
/interface/bridge/filter> print
Flags: X - disabled, I - invalid, D - dynamic
0 ;;; DHCP
chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832-orange-internet mac-protocol=ip dst-port=67 ip-protocol=udp log=no log-prefix=""
1 ;;; ARP
chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832-orange-internet mac-protocol=arp log=no log-prefix=""
2 ;;; NA/NS
chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832-orange-internet mac-protocol=ipv6 packet-mark=na/ns log=no log-prefix=""
3 ;;; DHCPV6
chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832-orange-internet mac-protocol=ipv6 dst-port=547 ip-protocol=udp packet-mark=no-mark log=no log-prefix=""
• Les options 61 (ipv4) et 1 (ipv6) sont construites à base de la Mac adress de la LB4.Et cette adresse Mac est clonée aussi sur le bridge ?
@jbfavre : Bizarre que tes règles bridge filter ne matchent rien. Chez moi elles matchent et semblent fonctionner.C'est bien mon problème :D
J'ai
5 ;;; set DSCP6 for DHCPv4
chain=output action=change-dscp new-dscp=48 passthrough=yes protocol=udp
out-interface=br-wan-vlan832 src-port=68 dst-port=67 log=yes log-prefix="set DSCP6 for DHCPv4"
6 ;;; set CoS6 for DHCPv4
chain=output action=set-priority new-priority=6 passthrough=yes protocol=udp
out-interface=br-wan-vlan832 src-port=68 dst-port=67 log=yes log-prefix="set CoS6 for DHCPv4 "
et 0 ;;; Router Solicitation RS
chain=output action=mark-packet new-packet-mark=cos6/dscp6 passthrough=yes protocol=icmpv6
dst-address=ff00::/8 out-interface=br-wan-vlan832 icmp-options=133:0-255
1 ;;; Neighbor Solicitation NS
chain=output action=mark-packet new-packet-mark=cos6/dscp6 passthrough=yes protocol=icmpv6
dst-address=fe80::ba0:bab/128 out-interface=br-wan-vlan832 icmp-options=135:0-255
2 ;;; Neighbor Advertisement NA
chain=output action=mark-packet new-packet-mark=cos6/dscp6 passthrough=yes protocol=icmpv6
dst-address=fe80::ba0:bab/128 out-interface=br-wan-vlan832 icmp-options=136:0-255
3 ;;; DHCPv6
chain=output action=mark-packet new-packet-mark=cos6/dscp6 passthrough=yes protocol=udp
out-interface=br-wan-vlan832 src-port=546 dst-port=547
4 ;;; set DSCP6 for RS/NS/NA
chain=output action=change-dscp new-dscp=48 passthrough=yes packet-mark=cos6/dscp6 log=no
log-prefix="set DSCP6 for RS/NS/NA"
5 ;;; set CoS6 for RS/NS/NA
chain=output action=set-priority new-priority=6 passthrough=yes packet-mark=cos6/dscp6 log=no
log-prefix="set CoS6 for RS/NS/NA"
Oui je sais que le design VLAN que j'ai est crade, mais :Je l'avais mis en place comme ça parce que:
- Il ne s'agit pas d'un switch. Le CCR2004 n'a pas de switch chip, et tout passe dans tous les cas par le CPU, donc dans tous les cas on ne "loupe" pas de hardware offload à cause du design crade : il n'y a pas de hardware offload puisque pas de switch
- Il n'y a qu'un seul VLAN, sur une seule interface. Et j'ai désactivé STP dessus, donc le traffic ne peut pas boucler, se rendre fou, ou quoi que ce soit : ya qu'une interface avec un seul VLAN dedans.
Je pense qu'utiliser les VLAN filters :
- Peut être la cause de ton problème
- Ne sert à rien car une fois de plus => il n'y a pas de switch chip, rien ne peut être offloadé (c'est très différent avec un switch de type CRS3XXXX où là en effet, il FAUT passer par les VLAN filters)
@jbfavre : Ca peut pas foutre le bordel dans tes autres VLANs, puisque ceux-ci seront dans un bridge différent ;-)Pas faux 😉
/interface/bridge/settings/set use-ip-firewall=yes
Et cette adresse Mac est clonée aussi sur le bridge ?
Il est indispensable d'avoir Mac du bridge = option 61 = option 1. Et inutile que ce soit celle d'une Livebox du moment que les 3 sont identiques (moi je clone celle de mon Ubiquiti ER4 pour pouvoir interchanger facilement ER4 et CCR2004 pendant la mise au point de ma config pour le CCR).
ce n'est pas celle de la LB4 et ce n'est pas modifiableC'est ça le problème, et c'est modifiable, il suffit de mettre l'interface en disabled, faire le changement, puis la réactiver. Si ça ne fonctionne pas depuis inbox alors il faut utiliser un terminal (c'est ce que j'ai fait perso).
Houlala, une merveille ça (merci pour le partage) :)
Je vais tester et je te ferai un retour avec mention @jbfavre
Autre problème désormais impossible de récupérer une IPV6 et je me demande si ne n'est pas à cause de mon DUID ?Content que le script t'ai servi.
Comment puis-je modifier le DUID afin qu'il corresponde aux éléments MAC de la LB4 (éléments que j'utilise désormais partout) mais ce n'était pas le cas avant.
Je vois dans mon DUID des éléments MAC de mon routeur et je voudrais faire tout matcher avec les infos MAC de la LB4 et figer la situation ensuite.
/ipv6/dhcp-client/set 0 use-interface-duid=yes
Content que le script t'ai servi.
Pour le DUID, il y a une option du /ipv6/dhcp-client qui te permet d'utiliser la mac de l'interface plutôt que le DUID interne du routeur (basé sur la MAC de l'interface au moment où tu actives IPv6):Code: [Sélectionner]/ipv6/dhcp-client/set 0 use-interface-duid=yes
Comme je suis en RouterOS 6.48, je n'ai pas l'option "use-interface-duid=yes"
client-option "send dhcp-client-identifier 1:<mac de ma livebox>;"Du coup l'adresse mac envoyée est différente de celle de eth1 (à moins d'avoir cloné l'adresse Mac de la livebox sur l'interface physique du routeur), et ça, ça n'est plus autorisé.
Je pense qu'il vaut mieux changer celle d'eth1 pour celle de la Livebox.Ce qui potentiellement (je n'ai pas véfifié quel effet ça a dans la table ARP du routeur) posera problème si on veut réutiliser la Livebox derrière le routeur pour la téléphonie, puisque que le routeur verra la même Mac pour son interface physique et pour un device auquel il est directement connecté.
Les rules bridge ou switch suffisent pour changer la COS.
Idéalement il faut aussi changer le DSCP, mais ce n'est pas obligatoire. Personnellement, je ne le fais pas.
Si tu y tiens vraiment, tu peux utiliser ça :
Pour changer le DSCP :Code: [Sélectionner]/ipv6 firewall mangle
add action=change-dscp chain=output comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - DHCPv6 - DSCP to 6" dst-port=547 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=udp src-port=546
Je prépare ces 4 règles pour le DSCP au-cas ou...
Ne pouvant utiliser qu'un bridge pour appliquer ces priorisations (pas de switch rule sur mon routeur Hex_s).
Dans ce cas le out-interface pour moi sera le bridge_wan (qui est le nom de mon bridge qui va sur le wan) ?
Merci pour vos conseils.
Yann
Oui
Hello,
C'est exactement ce que je fais sur mon RB5009.
Cos6 ip4, ipv6, arp sur le CRS310 avec les switch rule.
Et régles mangle ipv6 (Qui sont désactivées car pas obligatoire) pour le DSCP.
Je n'ai donc pas de bridge sur mon vlan832.
Mes régles mangle doivent être (je ne suis pas chez moi) les mêmes que celles données par @Cyayon sauf que j'utilise postrouting au lieu de output, ce que je vais certainement changer(après test) suite à la remarque de @Zoc.
Je suis sur une configuration similaire (CRS305 au lieu de CRS310), mais j'ai quand même gardé un bridge-wan sur le vlan832 pour définir son "Admin Mac Address" qui est utilisé sur pour l'inteface DUID du DHCP l'IPV6 et l'option 61 du DHCP IPV4. Pour le coup, j'ai utilisé la Mac Address de la LB, même s'il n'y a pas de contrôle côté Orange, je garde la maitrise sur l'adresse MAC présentée.
Après, est-ce la meilleure solution, ou bien l'utilisation de l'adresse MAC du vlan832 est-elle suffisante ? En tout cas ça fonctionne bien, en attendant que ma ligne soit migrée vers le nouveau système de contrôle (ce n'est toujours pas le cas)
J'ai donc fixé la mac de eth1 à celle de ma livebox. et compatible avec le dhcp option.
Réponse dans 24H pour voir si j'ai récupéré ma stabilité.
Dans ma config il n'y a pas d'ip V6.
Sur le repo : https://gitlab.com/skelettor/orange-isp-erl Il Y'a tout le nécessaire à l ip V6 à priori .
Est-ce que quelqu'un a un retour sur cette configuration ?
LB6 tu dois pouvoir monter à 2,5G, y'a un port 2,5 G dessus, en utilisant l'ONT interne de la LB6 pour le WAN
LeVieux
Dibbler prend l'adresse mac de eth0 pour générer son DUID lors de son premier lancement. Si l'ONT est sur eth1 alors le DUID ne sera pas bon et du coup pas de préfixe. Solution: Lancer une fois dibbler, l'arrêter, puis modifier le contenu du fichier /var/run/dibble-client-duid à la main.
Bonjour @levieux,Le "form factor" là il est étudié pour le "Wifi qui est super".
J'ai mis les LB6 en 2.5 et DMZ sur les différents sites concernés.
Je sais que c'est au "marketing" qu'il faudrait dire cela,
mais il faut avouer que LB6 a un form factor qui fait pleurer :'(
A+
Oui, j’avais donné le chemin de mémoire et il est possible que ma mémoire soit défaillante ;)
Le "form factor" là il est étudié pour le "Wifi qui est super".
Plus sérieusement, c'est effectivement liè à 2 choses :
- wifi et disposition des N antennes à l'intérieur
- circulation d'air pour le refroidissement passif.
Dans cette position (en plus dans une baie) je donne pas chère de la durée de vie de ta boxe. Où en tout cas à sa stabilité, quand le proc va chauffer, il va faire reboot de temps à autre. Sauf (vue que tu es dans une baie ...) si tu lui colle un ventillo ...
LeVieux
Mar 13 10:00:46 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 35420ms.
Mar 13 10:01:21 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 70100ms.
Mar 13 10:02:31 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 124420ms.
Mar 13 10:04:36 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 131780ms.
10:00:46.180659 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
10:01:21.601062 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
10:02:31.701472 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
10:04:36.121897 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
/sbin/dhclient -6 -P -cf /etc/dhcp/dhclient-v6.conf eth0.832
option dhcp6.client-id code 1 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
option dhcp6.canalretour code 17 = string;
lease-id-format hex;
interface "eth0.832" {
# 15
send dhcp6.userclass "+FSVDSL_livebox.Internet.softathome.Livebox4";
# 16
send dhcp6.vendorclass = "sagem";
# 11
# 90 : fti / XX ; YY
# https://jsfiddle.net/kgersen/3mnsc6wy/
send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:(...);
# 1
send dhcp6.client-id 00:03:00:01:b8:26:6c:f9:f7:14;
}
request dhcp6.auth, dhcp6.canalretour;
C'est pour cela que je ne comprends pas.C'est vrai que j'ai tendance à mieux maitriser la partie GP et "petits Pro".
Je gère plein de sites, il n'y a que des baies. Quelle entreprise n'a pas de baie ? et même :
petite entreprise == petite baie moins ventilée et jamais assez de place pour la mettre debout.
LB6 devient obligatoire avec les offres "Pro".
C'est désolant des solutions comme ça :/
PS: Le wifi est désactivé, de toutes les façons il ne couvre pas la surface des locaux (APs obligatoires).
Bonne journée
Bonjour,
J'ai été migré dans la nuit de jeudi à vendredi... J'ai réussi à récupérer l'ipv4, mais impossible de récupérer de l'ipv6.
Environnement: linux avec interface unique, vlan 832 ajouté dessus, cos géré par iptables et par le switch cisco sg300 qui fait le lien entre l'ONT et le routeur linux. Marche très bien en ipv4, passe en réseau de quarantaine si je modifie la COS, donc c'est que ça doit être bon. Seul l'ipv6 déconne, la conf COS ip6tables / mangle est identique à celle du v4.
Mes requêtes dhcp6 restent totalement sans réponse:
logs:Code: [Sélectionner]Mar 13 10:00:46 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 35420ms.
Mar 13 10:01:21 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 70100ms.
Mar 13 10:02:31 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 124420ms.
Mar 13 10:04:36 XXX.domain.tld dhclient[476992]: XMT: Solicit on eth0.832, interval 131780ms.
tcpdump:Code: [Sélectionner]10:00:46.180659 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
10:01:21.601062 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
10:02:31.701472 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
10:04:36.121897 IP6 fe80::ba26:6cff:fef9:f714.546 > ff02::1:2.547: dhcp6 solicit
Du coup je ne risque pas d'avoir d'option 17 puisque je n'ai aucun retour d'un serveur dhcp6...
Soft:Code: [Sélectionner]/sbin/dhclient -6 -P -cf /etc/dhcp/dhclient-v6.conf eth0.832
Conf:Code: [Sélectionner]option dhcp6.client-id code 1 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
option dhcp6.canalretour code 17 = string;
lease-id-format hex;
interface "eth0.832" {
# 15
send dhcp6.userclass "+FSVDSL_livebox.Internet.softathome.Livebox4";
# 16
send dhcp6.vendorclass = "sagem";
# 11
# 90 : fti / XX ; YY
# https://jsfiddle.net/kgersen/3mnsc6wy/
send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:(...);
# 1
send dhcp6.client-id 00:03:00:01:b8:26:6c:f9:f7:14;
}
request dhcp6.auth, dhcp6.canalretour;
Si quelqu'un a une idée... Sinon, ça va rester le protocole de demain.
Merci,
Arnaud.
(https://lafibre.info/images/free/202104_free_pro_kit_mis_en_baie_1.webp)
Le problème pour moi venait de l'information DUID du client IPV6 (pas cohérent avec les autres information de MAC envoyés) par ailleurs.
# 61
send dhcp-client-identifier = hardware;
# 1
send dhcp6.client-id 00:03:00:01:b8:26:6c:f9:f7:14;
# cat dhclient6.leases
default-duid 00:01:00:01:2b:9e:25:a4:b8:26:6c:f9:f7:14;
# grep dhcp-client dhclient.leases
option dhcp-client-identifier 1:b8:26:6c:f9:f7:14;
Bonjour,
Merci du retour.
Pourtant, mes info mac/duid me semblent bien cohérentes:
6: eth0.832@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b8:26:6c:f9:f7:14 brd ff:ff:ff:ff:ff:ff
v4:Code: [Sélectionner]# 61
send dhcp-client-identifier = hardware;
(Donc 01:b8:26:6c:f9:f7:14) (ne me demandez pas d'où vient le 01)
v6:Code: [Sélectionner]# 1
send dhcp6.client-id 00:03:00:01:b8:26:6c:f9:f7:14;
Ou alors sur le v6 il faut virer le "00:03:00" ?
Testé: En virant le 00:03:00 et en ayant ""send dhcp6.client-id 01:b8:26:6c:f9:f7:14;" ça ne change rien. Toujours le solicit, aucun retour... :(Code: [Sélectionner]# cat dhclient6.leases
default-duid 00:01:00:01:2b:9e:25:a4:b8:26:6c:f9:f7:14;
# grep dhcp-client dhclient.leases
option dhcp-client-identifier 1:b8:26:6c:f9:f7:14;
Je n'arrive pas à faire correspondre parfaitement les deux :|
# cat dhclient6.leases
default-duid 00:01:00:01:2b:9e:25:a4:b8:26:6c:f9:f7:14;
Du coup, j'ai toujours des déconnexions toutes les 24 h
Je tente en ne mettant pas la mac de la box mais celle de l eth1 du routeur
Pas mieux au bout de 23h une nouvelle déconnexion : reboot et ok ...
client-option "send dhcp-client-identifier 01:b4:fb:e4:2e:d0:c8;" (mac de mon eth1)
link/ether b4:fb:e4:2e:d0:c8 brd ff:ff:ff:ff:ff:ff
inet xxxxxxxxx/21 brd xxxxxx.255 scope global eth1.832
Est ce que qu"lqu'un a une configuration stable sans ipv6 ?
option dhcp.userclass code 77 = string;
option dhcp.rfc3118-authentication code 90 = string;
option dhcp.retour code 125 = string;
lease-id-format hex;
interface "eth0.832" {
# 60
send vendor-class-identifier = "sagem";
# 61
send dhcp-client-identifier = hardware;
# 77
send userclass "+FSVDSL_livebox.Internet.softathome.Livebox4";
# 90 : fti / ; password:
# https://jsfiddle.net/kgersen/3mnsc6wy/
send rfc3118-authentication 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:01:03:41:(etc).
}
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
netbios-name-servers, netbios-scope, interface-mtu,
ntp-servers, retour;
/sbin/dhclient -4 -cf /etc/dhcp/dhclient-v4.conf eth0.832
#! /bin/bash
/sbin/ethtool -K eth0 tso off
/sbin/ip link add link eth0 name eth0.832 type vlan id 832
# Use livebox MAC
/sbin/ip link set dev eth0.832 address A4:08:BB:CC:DD:EF
# On modifie la priorité de la file 1 à 0 c'est là qu'on renverra tout nos paquets, la file 0 qui est celle par défaut passe à 6
/sbin/ip link set dev eth0.832 type vlan egress-qos-map 0:6 1:0 2:2 3:3 4:4 5:5 6:6 7:7
# IPV4
# Tous les protocoles changent de file vers le skb 01 dont on a mis la prio à 0
iptables -t mangle -A POSTROUTING -o eth0.832 -j CLASSIFY --set-class 0000:0001
# On maintient les paquets réseaux dans une file à prio 6
iptables -t mangle -A POSTROUTING -o eth0.832 -p igmp -j CLASSIFY --set-class 0000:0006
iptables -t mangle -A POSTROUTING -o eth0.832 -p icmp -j CLASSIFY --set-class 0000:0006
# Les paquets VOIP(téléphonie orange) sont taggués EF ont les met en prio 5
iptables -t mangle -A POSTROUTING -o eth0.832 -m dscp --dscp 0x2e -j CLASSIFY --set-class 0000:0005
# Si votre client DHCP n'utilise pas les raw socket il faut envoyer les paquet DHCP dans la file 6 (prio 6)
iptables -t mangle -A POSTROUTING -o eth0.832 -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
# Finally, launch dhclient
/sbin/dhclient -4 -cf /etc/dhcp/dhclient-v4.conf eth0.832
Mar 12 10:27:55 gw.domain.tld dhclient[3953]: DHCPREQUEST for 90.62.YY.ZZ on eth0.832 to 80.10.233.141 port 67
Mar 12 10:27:55 gw.domain.tld dhclient[3953]: DHCPACK of 90.62.YY.ZZ from 80.10.233.141
Mar 12 10:27:55 gw.domain.tld dhclient[3953]: bound to 90.62.YY.ZZ -- renewal in 75365 seconds.
Mar 13 07:24:00 gw.domain.tld dhclient[3953]: DHCPREQUEST for 90.62.YY.ZZ on eth0.832 to 80.10.233.141 port 67
Mar 13 07:24:00 gw.domain.tld dhclient[3953]: DHCPACK of 90.62.YY.ZZ from 80.10.233.141
Mar 13 07:24:00 gw.domain.tld dhclient[3953]: bound to 90.62.YY.ZZ -- renewal in 83074 seconds.
Sur deux sites en ipv4, j'ai du stable, ça bouge pas:
Bon par contre, le V6, toujours pas. Il faudrait un exemple de cilentid v4 et un en v6 pour comparer...
add code=61 name=clientid value=0x0144A6xxxxxxxx (basée sur la MAC de la LB4)
add code=1 name=clientid value=0x0003000144A6xxxxxxxx (basée sur la MAC de la LB4)
Code: [Sélectionner]add code=61 name=clientid value=0x0144A6xxxxxxxx (basée sur la MAC de la LB4)Code: [Sélectionner]add code=1 name=clientid value=0x0003000144A6xxxxxxxx (basée sur la MAC de la LB4)
# 61
send dhcp-client-identifier = hardware;
# ce qui donne:
# option dhcp-client-identifier 1:b8:26:AA:BB:CC:DD;
option dhcp6.client-id code 1 = string;
# 1
send dhcp6.client-id 00:03:00:01:b8:26:AA:BB:CC:DD;
# Ce qui donne:
# default-duid 00:01:00:01:2b:a1:ba:ec:b8:26:AA:BB:CC:DD;
Hello,
Top, merci beaucoup pour les exemples. Seul problème: j'envoie bien exactement la même chose, mon problème serait donc ailleurs (comme la vérité quoi hein)...
V4:Code: [Sélectionner]# 61
send dhcp-client-identifier = hardware;
# ce qui donne:
# option dhcp-client-identifier 1:b8:26:AA:BB:CC:DD;
V6:Code: [Sélectionner]option dhcp6.client-id code 1 = string;
# 1
send dhcp6.client-id 00:03:00:01:b8:26:AA:BB:CC:DD;
# Ce qui donne:
# default-duid 00:01:00:01:2b:a1:ba:ec:b8:26:AA:BB:CC:DD;
Je ne vois pas du coup. Je rate un truc ? Une autre paire d'yeux que la mienne pourrait-il m'indiquer où nettoyer mes lunettes ? :-)
0000040e0005736167656dCeci étant pour cette option, @levieuxatorange n'a pas précisé si elle était obligatoire.00030001b826AABBCCDDLe DUID n'a pas nécessairement à être le même que la Livebox. Il faut juste que l'option 61 en IPv4 et 1 en IPv6 soit cohérente, ce qui est le cas ici.L'option 16 ne semble pas correcte. La valeur devrait être en hexa :Code: [Sélectionner]0000040e0005736167656dCeci étant pour cette option, @levieuxatorange n'a pas précisé si elle était obligatoire.
Pour l'option 1 en IPv6, la valeur doit être envoyée en hexa. Est ce bien le cas ?
Dans ton cas, le DUID devrait êtreCode: [Sélectionner]00030001b826AABBCCDDLe DUID n'a pas nécessairement à être le même que la Livebox. Il faut juste que l'option 61 en IPv4 et 1 en IPv6 soit cohérente, ce qui est le cas ici.
Avant la migration tu avais bien l'IPv6 ?
option dhcp6.client-id code 1 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
option dhcp6.canalretour code 17 = string;
lease-id-format hex;
#Replace eth0 with your external interface (VLAN must be 832 for Orange)
interface "eth0.832" {
#Orange France specific options
# 15: Livebox *4*
send dhcp6.userclass 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;
# 16 Sagem
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
# 11
# 90 : fti / XXX ; password: YYY
# https://jsfiddle.net/kgersen/3mnsc6wy/
send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:1a:(etc);
# 1 ; "b8:26:AA:BB:CC:DD" is the livebox mac address (must be consistent with v4)
send dhcp6.client-id 00:03:00:01:b8:26:AA:BB:CC:DD;
}
request dhcp6.auth, dhcp6.canalretour;
Bonjour,
Bon, avec un nouveau café et une nuit de sommeil, je viens de tenter en repassant tous les paramètres en hexa... Et là, j'ai une conf qui marche:
Merci à tout ceux qui ont répondu, sans le soutien, je pense que j'aurais lâché l'affaire !
Arnaud, heureux de bien commencer sa journée.
Code: [Sélectionner]# 15: Livebox *4*
send dhcp6.userclass 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;
Bonne nouvelle !
Par souci du détail, l'option 15 que tu indiques correspond à une Livebox 3 (mais ça ne porte pas à conséquences).
J'utilise un script sur mes dhcp-client pour vérifier la valeur des option 125 et 17.
Pour DHCPv4:Code: [Sélectionner]/ip dhcp-client add comment="Orange public IPv4" dhcp-options=vendor-class,user-class,authentication,clientid interface=<TON_INTERFACE> script="{\Et DHCPv6:
\n :if (\$bound=1) do={\
\n foreach option,value in=\$\"lease-options\" do={\
\n :if (\$option=\"125\") do={\
\n :log debug \"IPv4: Found [\$value]\";\
\n :global class [:pick \$value 11];\
\n :log debug \"Extracted [\$class]\";\
\n :if (\$class=\"\\00\") do={\
\n :log info \"IPv4: ISP network is OK\";\
\n };\
\n :if (\$class=\"\\01\") do={\
\n :log error \"IPv4: Technical blacklist\";\
\n };\
\n :if (\$class=\"\\02\") do={\
\n :log error \"IPv4: Auth or encoding failure\";\
\n };\
\n :if (\$class=\"\\03\") do={\
\n :log error \"IPv4: Account or service probably terminated\";\
\n };\
\n :if (\$class=\"\\04\") do={\
\n :log error \"IPv4: Invoice payment problem.\";\
\n };\
\n :if (\$class=\"\\99\") do={\
\n :log error \"IPv4: CoS & DSCP issue.\";\
\n };\
\n }\
\n }\
\n }\
\n}"Code: [Sélectionner]/ipv6 dhcp-client add add-default-route=yes comment="Orange public IPv6 prefix delegation" dhcp-options=authentication,user-class,vendor-class dhcp-options=authentication,user-class,vendor-class interface=<TON_INTERFACE> pool-name=pool-v6orange rapid-commit=no request=prefix script="{\
\n :if (\$\"pd-valid\"=1) do={\
\n foreach option,value in=\$options do={\
\n :if (\$option=\"17\") do={\
\n :log debug \"IPv6: Found [\$value]\";\
\n :global class [:pick \$value 11];\
\n :log debug \"Extracted [\$class]\";\
\n :if (\$class=\"\\00\") do={\
\n :log info \"IPv6: ISP network is OK\";\
\n };\
\n :if (\$class=\"\\01\") do={\
\n :log error \"IPv6: Technical blacklist\";\
\n };\
\n :if (\$class=\"\\02\") do={\
\n :log error \"IPv6: Auth or encoding failure\";\
\n };\
\n :if (\$class=\"\\03\") do={\
\n :log error \"IPv6: Account or service probably terminated\";\
\n };\
\n :if (\$class=\"\\04\") do={\
\n :log error \"IPv6: Invoice payment problem.\";\
\n };\
\n :if (\$class=\"\\99\") do={\
\n :log error \"IPv6: CoS & DSCP issue.\";\
\n };\
\n }\
\n }\
\n }\
\n}" use-interface-duid=yes use-peer-dns=no
000005580c010a0001000000ffffffffffCe qui, une fois convertie en texte, correspond à une chaine de 16 caractères (manifestement, RouterOS ne travaille pas sur la chaine brute).Le canal retour :
Dans la réponse DHCP il y a un canal de retour du réseau.
C'est l'option 125 en DHCPv4, l'option 17 en DHCPv6
Le contenu (attention, les entêtes des options sont différentes, voir les RFC) est le même et dans le format suivant avec en rouge 2 octets de code d'information : 0001000000ffffffffff
Les grandes classes de réponses sont :
- 00xx : OK vu du réseau Orange et tout doit fonctionner. Si ce n'est pas le cas le problème vient de chez vous.
- 01xx : Le modèle de box, le firmware ou votre ligne est bloquée (0102 ce qui peut arriver si le comportement de votre routeur est trop agressif ...) 0199 en cas de mauvaise COS sur le DHCP
- 02xx : erreur de Login ou de Mot de passe ou d'encodage
- 03xx : compte ou service probablement résilié
- 04xx : problème de règlement de la facture avec de possibles limitation de débit ou blocage.
LeVieux
Bonjour,
J'ai une question concernant le script ci-dessus.
Lorsqu'on utilise la fonction :pick le premier index est 0.
L'option 125 brute telle que reçue par le Mikrotik est de la formeCode: [Sélectionner]000005580c010a0001000000ffffffffffCe qui, une fois convertie en texte, correspond à une chaine de 16 caractères (manifestement, RouterOS ne travaille pas sur la chaine brute).
Or, @levieuxatorange indique
Ainsi, ne faut il pas récupérer le caractère dont l'index est 10 plutôt que 11 ?
Hello @yeocti+1
De mémoire, j'ai un caractère non imprimable qui bouffe un offset sans ce que soit exploitable. Je ne sais pas si c'est Orange qui l'ajoute, ou Mikrotik qui fait des chocapic en parsant l'option, j'avoue que je n'ai pas trop cherché.
Tu devrais pouvoir vérifier en modifiant le script pour pick chaque octet et générer un log.
De mémoire, j'ai un caractère non imprimable qui bouffe un offset sans ce que soit exploitable.
Tu peux lire le log via SSH aussi (/log/print) pour le lire, normalement ton client devrait être compatible UTF-8
option dhcp6.client-id code 1 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
option dhcp6.vendor-opts code 17 = string;
option rfc3118-auth code 90 = string;
#Replace eth0 with your external interface (VLAN must be 832 for Orange)
interface "eth0.832" {
send dhcp-client-identifier 01:30:7C:B2:XX:XX:XX;
send vendor-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:xxxxxxxxxxxxxxxx;
# Orange France specific options
# sagem
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
# livebox 4
send dhcp6.userclass 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;
# vendor specific information (option 17): entreprise id "Orange" 4 octets 00000558 + 2 octets option code 0006 + 14 octets Option data: 495056365f524551554553544544 ("IPV6_REQUESTED")
send dhcp6.vendor-opts 00:00:05:58:00:06:00:0e:49:50:56:36:5f:52:45:51:55:45:53:54:45:44;
#Authentication to Orange France DHCP server (meme valeur pour ipv4)
send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:1a:xxxxxxxx;
#Replace xx:xx:xx:xx:xx:xx with the MAC address of your external interface
send dhcp6.client-id 00:03:00:01:30:7C:B2:XX:XX:XX;
request dhcp6.auth, dhcp6.vendor-opts, dhcp6.name-servers, dhcp6.domain-search;
}
dhclient -6 -d -v -cf dhclient_eth0.832.conf
Internet Systems Consortium DHCP Client 4.1-ESV-R15-P1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on Socket/eth0.832
Sending on Socket/eth0.832
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT: X-- IA_NA b2:3d:dd:eb
XMT: | X-- Request renew in +3600
XMT: | X-- Request rebind in +5400
XMT: Solicit on eth0.832, interval 1040ms.
RCV: Advertise message on eth0.832 from fe80::ba0:bab.
RCV: X-- IA_NA b2:3d:dd:eb
RCV: | X-- starts 1678919447
RCV: | X-- t1 - renew +0
RCV: | X-- t2 - rebind +0
RCV: | X-- [Options]
RCV: | !-- Status code of no addrs, IA_NA discarded.
RCV: X-- Server ID: 00:03:00:01:14:7b:ac:aa:9a:bf
PRC: Lease failed to satisfy.
Chain POSTROUTING (policy ACCEPT 110K packets, 21M bytes)
pkts bytes target prot opt in out source destination
48 11793 CLASSIFY udp * * ::/0 ::/0 udp dpt:547 CLASSIFY set 0:6
DHCPv6:
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
l'encodage Hexa de ce qui est ci dessus : 00 01 00 0a 00 03 00 01 44 d4 54 XX XX XX
[onishin@Styx] > :put ([($toolObj->"get") "lafibre.info"]) ;
79386a71d470aa9fc6d10efe36ed23d7
$ echo -en "lafibre.info" | md5sum-
79386a71d470aa9fc6d10efe36ed23d7
On a une idée de comment orange choisis le SALT ?
Random ? Ou il incrémente sans arrêt ?
Comme j'ai des coupures aléatoirement, j'ai bien envie de tester avec des options 90 et 11 complètement différente a chaque fois.
Apparemment avec le langage de script mikrotik on peut faire pas mal de chose.
https://github.com/merlinthemagic/MTM-RouterOS-Scripting/blob/main/src/v7/Documentation/Tools/Hashing/MD5.md
-
Je me dis que 1 jour ils vont empêcher le rejeux des requetes
Je me dis que 1 jour ils vont empêcher le rejeux des requetesC'est l'idée, il y en a d'autres aussi :)
C'est l'idée, il y en a d'autres aussi :)
C'est toujours mieux si vous y arrivez, mais pour le moment pas d'obligation.
Levieux
Effectivement, bonne idée pour le salt renew a chaque foisPour peu que ça n'entraine pas un redémarrage complet du client DHCP et donc un RELEASE puis DISCOVER, où que le changement soit ignoré jusqu'à un renew manuel... Perso j'ai comme un doute que ça soit faisable sans l'aide de Mikrotik.
Pour peu que ça n'entraine pas un redémarrage complet du client DHCP et donc un RELEASE puis DISCOVER, où que le changement soit ignoré jusqu'à un renew manuel... Perso j'ai comme un doute que ça soit faisable sans l'aide de Mikrotik.La modification des options DHCP (/ip(v6)/dhcp-client/option/set) n'entraine pas de redémarrage du client. C'est au moins un bon point.
La modification des options DHCP (/ip(v6)/dhcp-client/option/set) n'entraine pas de redémarrage du client. C'est au moins un bon point.Oui, mais l'autre question est essentielle :-) : Les modifications sont-elles prises en compte pour le renew suivant ?
Mar 16 18:21:07 ipc logger[188439]: ipv6-setup is called, reason=DEPREF6
Mar 16 18:21:07 ipc dhclient[1308]: PRC: Prefix 2a01:xxxx:xxxx:xxxx::/56 depreferred.
Mar 16 18:21:07 ipc logger[188448]: ipv6-setup is called, reason=EXPIRE6
Salut,Hello
Je ne comprends pas trop la motivation technique derrière ça. Quel est l'intérêt pour Orange d'empêcher le rejeu ?
Empêcher les gens d'utiliser autre chose que la Livebox ?
/ipv6/dhcp-client/set 0 script="{ /ipv6/dhcp-client/option/set [find where code=\"11\"] value=\"0x00\" ; /import WIP-MTK-generateOrangeAuth.rsc }"On évite donc de toucher aux deux options (v4 & v6) à chaque transaction./ip/dhcp-client/option/set [find where code="90"] value="0x00"
/ipv6/dhcp-client/option/set [find where code="11"] value="0x00"
/import WIP-MTK-generateOrangeAuth.rsc/ip/dhcp-client/set 0 script="{ /ip/dhcp-client/option/set [find where code=\"90\"] value=\"0x00\" ; /import WIP-MTK-generateOrangeAuth.rsc }"
/ipv6/dhcp-client/set 0 script="{ /ipv6/dhcp-client/option/set [find where code=\"11\"] value=\"0x00\" ; /import WIP-MTK-generateOrangeAuth.rsc }"
c'est bien ca ?/ip/dhcp-client/option/set [find where code="90"] value="0x00"
/ipv6/dhcp-client/option/set [find where code="11"] value="0x00"
/import WIP-MTK-generateOrangeAuth.rsc
T125 Option 125, length 17: 0.0.5.88.12.1.10.0.1.0.2.1.0.0.0.0.0Le canal retour :
Dans la réponse DHCP il y a un canal de retour du réseau.
C'est l'option 125 en DHCPv4, l'option 17 en DHCPv6
Le contenu (attention, les entêtes des options sont différentes, voir les RFC) est le même et dans le format suivant avec en rouge 2 octets de code d'information : 0001000000ffffffffff
Les grandes classes de réponses sont :
- 00xx : OK vu du réseau Orange et tout doit fonctionner. Si ce n'est pas le cas le problème vient de chez vous.
- 01xx : Le modèle de box, le firmware ou votre ligne est bloquée (0102 ce qui peut arriver si le comportement de votre routeur est trop agressif ...) 0199 en cas de mauvaise COS sur le DHCP
- 02xx : erreur de Login ou de Mot de passe ou d'encodage
- 03xx : compte ou service probablement résilié
- 04xx : problème de règlement de la facture avec de possibles limitation de débit ou blocage.
#!/bin/bash
login='fti/xxxx'
pass='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-30)
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})
@TarKok
• En DHCPv4, l'option 61 devient obligatoire
Tu envoies bien l'option 61 qui devient obligatoire avec la migration.
Excuses moi si tu l'appliqais peut être déjà avant?
Hello, merci pour ta réponse. J'avais vu ça et j'ai vérifié, l'option 61 est bien dans ma configuration et je la vois passer dans mes captures. Je suis un peu à court d'idée...
Les rules bridge ou switch suffisent pour changer la COS.
Idéalement il faut aussi changer le DSCP, mais ce n'est pas obligatoire. Personnellement, je ne le fais pas.
Si tu y tiens vraiment, tu peux utiliser ça :
Pour changer le DSCP :Code: [Sélectionner]/ipv6 firewall mangle
add action=change-dscp chain=output comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - DHCPv6 - DSCP to 6" dst-port=547 new-dscp=6 out-interface=vlan832-wan passthrough=yes protocol=udp src-port=546
Pour changer la COS (mais déjà fait avec les switch ou bridge rules) :Code: [Sélectionner]/ipv6 firewall mangle
add action=set-priority chain=output comment="Orange - icmpv6 (type 133 - RS) - COS to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=set-priority chain=output comment="Orange - icmpv6 (type 136 - NA) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=set-priority chain=output comment="Orange - icmpv6 (type 135 - NS) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=icmpv6
add action=set-priority chain=output comment="Orange - DHCPv6 - COS to 6" dst-port=547 new-priority=6 out-interface=vlan832-wan passthrough=yes protocol=udp src-port=546
/ipv6 firewall mangle
add action=change-dscp chain=output comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=48 out-interface=bridge_wan \
passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=48 out-interface=\
bridge_wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=48 out-interface=\
bridge_wan passthrough=yes protocol=icmpv6
add action=change-dscp chain=output comment="Orange - DHCPv6 - DSCP to 6" dst-port=547 new-dscp=48 out-interface=bridge_wan passthrough=yes protocol=udp src-port=546
/ipv6 firewall mangle
add action=mark-packet chain=output comment="Orange - icmpv6 (type 133 - RS) - mark packet for COS6" dst-address=ff00::/8 icmp-options=133:0-255 new-packet-mark=na/ns \
out-interface=bridge_wan passthrough=no protocol=icmpv6
add action=mark-packet chain=output comment="Orange - icmpv6 (type 136 - NA) - mark packet for COS6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-packet-mark=na/ns \
out-interface=bridge_wan packet-mark="" passthrough=no protocol=icmpv6
add action=mark-packet chain=output comment="Orange - icmpv6 (type 135 - NS) - mark packet for COS6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-packet-mark=na/ns \
out-interface=bridge_wan passthrough=no protocol=icmpv6/interface bridge filter
add action=set-priority chain=output comment="DHCPv4 - COS6" dst-port=67 ip-protocol=udp log-prefix="[COS6] DHCP " mac-protocol=ip new-priority=6 out-bridge=bridge_wan out-interface=vlan832_wan passthrough=yes src-port=68
add action=set-priority chain=output comment="IPv6 NA/NS - COS6" mac-protocol=ipv6 new-priority=6 out-interface=vlan832_wan packet-mark=na/ns passthrough=yes
add action=set-priority chain=output comment="ARP - COS6" mac-protocol=arp new-priority=6 out-interface=vlan832_wan passthrough=yes
add action=set-priority chain=output comment="DHCPv6 - COS6" dst-port=547 ip-protocol=udp mac-protocol=ipv6 new-priority=6 out-interface=vlan832_wan packet-mark=no-mark passthrough=yes
Hello,
Je ne change pas le DSCP, la COS suffit, donc je n'ai pas vraiment testé. Si en sniffant, ba0bab répond avec 48, alors tu as certainement raison.
Merci en tout cas, je mets à jour ma doc :) au cas où...
Super script !Avant tout, le script doit être placé (par FTP/sftp) sur le routeur (après avoir renseigné les identifiants).
par contre, je n'ai bien compris le process d'install.
/import WIP-MTK-generateOrangeAuth.rsc/ip/dhcp-client/option/set [find where code="90"] value="0x00"
/ipv6/dhcp-client/option/set [find where code="11"] value="0x00"on lance le script/import WIP-MTK-generateOrangeAuth.rscon contrôle que les options sont bien générées/ip/dhcp-client/option/print
/ipv6/dhcp-client/option/printet qu'elles sont acceptées par orange/ip/dhcp-client/renew 0
/ipv6/dhcp-client/renew 0/system/logging/add topics=dhcpet pour consulter/log/print/ip/dhcp-client/set 0 script="{ /ip/dhcp-client/option/set [find where code=\"90\"] value=\"0x00\" ; /import WIP-MTK-generateOrangeAuth.rsc }"
/ipv6/dhcp-client/set 0 script="{ /ipv6/dhcp-client/option/set [find where code=\"11\"] value=\"0x00\" ; /import WIP-MTK-generateOrangeAuth.rsc }"pour regénérer les options après chaque consommation par le DHCPAvant tout, le script doit être placé (par FTP/sftp) sur le routeur (après avoir renseigné les identifiants).
On peut dire que c'est ça l'installation.
Lorsque c'est effectué, pour le lancer manuellement depuis la ligne de commande :Code: [Sélectionner]/import WIP-MTK-generateOrangeAuth.rsc
Si on veut tester en manuel, on "efface" les identifiants :Code: [Sélectionner]/ip/dhcp-client/option/set [find where code="90"] value="0x00"on lance le script
/ipv6/dhcp-client/option/set [find where code="11"] value="0x00"Code: [Sélectionner]/import WIP-MTK-generateOrangeAuth.rscon contrôle que les options sont bien généréesCode: [Sélectionner]/ip/dhcp-client/option/printet qu'elles sont acceptées par orange
/ipv6/dhcp-client/option/printCode: [Sélectionner]/ip/dhcp-client/renew 0
/ipv6/dhcp-client/renew 0
(edit) pour voir ce qu'il se passe au niveau DHCP, il peut être utile d'activer les logs DHCPCode: [Sélectionner]/system/logging/add topics=dhcpet pour consulterCode: [Sélectionner]/log/print
Et ensuite, oui, on peut l'automatiser de la manière suivanteCode: [Sélectionner]/ip/dhcp-client/set 0 script="{ /ip/dhcp-client/option/set [find where code=\"90\"] value=\"0x00\" ; /import WIP-MTK-generateOrangeAuth.rsc }"pour regénérer les options après chaque consommation par le DHCP
/ipv6/dhcp-client/set 0 script="{ /ipv6/dhcp-client/option/set [find where code=\"11\"] value=\"0x00\" ; /import WIP-MTK-generateOrangeAuth.rsc }"
Concernant le "watchdog" c'est un autre script optionnel, qui n'existe pas chez tout le monde (loin de là)
Je pourrai éventuellement poster le mien prochainement.
J'ai été migré cette nuit également avec perte de connectivité v6/v4 à la clef. Pas de perte de lien en sortie d'ONT, probablement juste un reset du BNG ou autre.
Un petit down/up de l'interface connecté à l'ONT (qui a eu pour effet de relancer les clients DHCP du routeur) et tout est rentré dans l'ordre. Bail de 7 jours pour mon /56.
Aussi pour lever le doute sur la chaine option 90, possibilité d'envoyer une chaine fixe générée par le script de @kgersen pour les tests:
https://jsfiddle.net/kgersen/3mnsc6wy/
Permettra de savoir s'il faut chercher de ce coté ou ailleurs...
Tu ne fais que de l' IPV4 pour l'instant ?
send dhcp-client-identifier 01:xx:xx:xx:xx:xx:xx;@cyayon @proap
DSCP:
Effectivement, personellement je mets la valeur 48 (qui est le codage élargi de la TOS) dans la nouvelle RFC.
Aussi je ne met pas la règle NA (type 136) car c'est une réponse au NS.
NA n'est pas en output wan de la box?
@cyayon est ce que tu peux nous confirmer ? Merci.
NA est en effet la réponse à des NS. D'après les informations de @levieuxatorange en première page, il faut bien faire la COS6 pour les messages NS/NA vers baobab. Je n'ai pas bien compris pourquoi tu penses que les NA ne devraient pas être taggés?
C:\Windows\System32>ping ipv6.google.com
Pinging ipv6.l.google.com [2a00:1450:4001:82b::200e] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 2a00:1450:4001:82b::200e:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\System32>
C:\Windows\System32>ping ipv6.google.com
Pinging ipv6.l.google.com [2a00:1450:4001:82b::200e] with 32 bytes of data:
Reply from 2a00:1450:4001:82b::200e: time=15ms
Reply from 2a00:1450:4001:82b::200e: time=15ms
Reply from 2a00:1450:4001:82b::200e: time=15ms
Reply from 2a00:1450:4001:82b::200e: time=15ms
Ping statistics for 2a00:1450:4001:82b::200e:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 15ms, Average = 15ms
C:\Windows\System32>
/ipv6 firewall mangle add action=change-dscp chain=output comment="icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=48 out-interface=bridge_wan passthrough=yes protocol=icmpv6
Avant tout, le script doit être placé (par FTP/sftp) sur le routeur (après avoir renseigné les identifiants).
On peut dire que c'est ça l'installation.
La règle que j'utilise et donc celle que je dois désactiver:Code: [Sélectionner]/ipv6 firewall mangle add action=change-dscp chain=output comment="icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=48 out-interface=bridge_wan passthrough=yes protocol=icmpv6
/ipv6 firewall mangle
add action=jump chain=postrouting comment="Jump to postrouting-wan-icmpv6" dst-address=fe00::/7 jump-target=postrouting-wan-icmpv6 out-interface=vlan832-wan protocol=icmpv6
add action=jump chain=postrouting comment="Jump to postrouting-wan-dhcpv6" dst-address=ff00::/8 dst-port=547 jump-target=postrouting-wan-dhcpv6 out-interface=vlan832-wan protocol=udp \
src-port=546
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-priority=6 passthrough=\
yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=6 passthrough=yes \
protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-priority=6 passthrough=\
yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=6 passthrough=yes \
protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - COS to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-priority=6 passthrough=yes \
protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=6 passthrough=yes protocol=\
icmpv6
add action=accept chain=postrouting-wan-icmpv6 comment="Default accept (postrouting-wan-icmpv6)"
add action=set-priority chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - COS to 6" new-priority=6 passthrough=yes
add action=change-dscp chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - DSCP to 6" new-dscp=6 passthrough=yes
add action=accept chain=postrouting-wan-dhcpv6 comment="Default accept (postrouting-wan-dhcpv6)"
J'ai les regles suivante et tout fonctionne bien. L'interface WAN est vlan832-wan. Je mets la DSCP à 6 en revanche.Code: [Sélectionner]/ipv6 firewall mangle
add action=jump chain=postrouting comment="Jump to postrouting-wan-icmpv6" dst-address=fe00::/7 jump-target=postrouting-wan-icmpv6 out-interface=vlan832-wan protocol=icmpv6
add action=jump chain=postrouting comment="Jump to postrouting-wan-dhcpv6" dst-address=ff00::/8 dst-port=547 jump-target=postrouting-wan-dhcpv6 out-interface=vlan832-wan protocol=udp \
src-port=546
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-priority=6 passthrough=\
yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=6 passthrough=yes \
protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-priority=6 passthrough=\
yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=6 passthrough=yes \
protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - COS to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-priority=6 passthrough=yes \
protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=6 passthrough=yes protocol=\
icmpv6
add action=accept chain=postrouting-wan-icmpv6 comment="Default accept (postrouting-wan-icmpv6)"
add action=set-priority chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - COS to 6" new-priority=6 passthrough=yes
add action=change-dscp chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - DSCP to 6" new-dscp=6 passthrough=yes
add action=accept chain=postrouting-wan-dhcpv6 comment="Default accept (postrouting-wan-dhcpv6)"
@fftmeh
Sympa les règles dans mangle. Du coup, ce n'est pas comme en ipv4, pas besoin d'utiliser les bridges filter du tout?
tu peux montrer ta règle qui manque dans la chaine postrouting-wan-dhcpv6, stp?
En IPv4 j'ai un CRS305 qui fait les changements nécessaires pour la COS et DSCP.
Pour IPv6, il y bien toutes les règles que j'utilise (une pour la COS, une pour DSCP). J'ai fait deux nouvelles chains afin de ne limiter les paquets qui sont vus par ces règles.
Frame 2: 230 bytes on wire (1840 bits), 230 bytes captured (1840 bits)
Ethernet II, Src: Nokia_b9:6e:ea (00:d0:f6:b9:6e:ea), Dst: Sagemcom_ff:ff:ff (44:d4:ff:ff:ff:ff)
Internet Protocol Version 6, Src: fe80::ba0:bab, Dst: fe80::ffff:ffff:ffff:ffff
0110 .... = Version: 6
.... 1100 0000 .... .... .... .... .... = Traffic Class: 0xc0 (DSCP: CS6, ECN: Not-ECT)
.... 1100 00.. .... .... .... .... .... = Differentiated Services Codepoint: Class Selector 6 (48)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 176
Next Header: UDP (17)
Hop Limit: 255
Source Address: fe80::ba0:bab
Destination Address: fe80::ffff:ffff:ffff:ffff
[Destination SLAAC MAC: Sagemcom_ff:ff:ff (44:d4:ff:ff:ff:ff)]
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6
En IPv4 j'ai un CRS305 qui fait les changements nécessaires pour la COS et DSCP.
Pour IPv6, il y bien toutes les règles que j'utilise (une pour la COS, une pour DSCP). J'ai fait deux nouvelles chains afin de ne limiter les paquets qui sont vus par ces règles.
V4 fonctionne, je lance V6, ça coupe V4. Je coupe V6, je relance V4, ça remarche...
Par contre, je pense que le DSCP (TOS) devrait être 48. Regarde la capture WireShark de la réponse de fe80:ba0:bab:
Si oui, comment changes-tu le DSCP avec des switchs rules ?
/interface ethernet switch rule
add comment="Orange DHCPv4 - CoS to 6" dst-port=67 mac-protocol=ip new-vlan-priority=6 ports=Router protocol=udp src-port=68 switch=switch1 vlan-id=832
add comment="Orange DHCPv6 - CoS to 6" dst-port=547 mac-protocol=ipv6 new-vlan-priority=6 ports=Router protocol=udp src-port=546 switch=switch1 vlan-id=832
add comment="Orange arp - CoS to 6" mac-protocol=arp new-vlan-priority=6 ports=Router switch=switch1 vlan-id=832
/ip firewall mangle
add action=change-dscp chain=postrouting comment="Orange - DHCPv4 - DSCP to 6" dst-port=67 new-dscp=48 out-interface=vlan832-wan passthrough=yes protocol=udp src-port=68
/ipv6 firewall mangle
add action=jump chain=postrouting comment="Jump to postrouting-wan-icmpv6" dst-address=fe00::/7 jump-target=postrouting-wan-icmpv6 out-interface=vlan832-wan protocol=icmpv6
add action=jump chain=postrouting comment="Jump to postrouting-wan-dhcpv6" dst-address=ff00::/8 dst-port=547 jump-target=postrouting-wan-dhcpv6 out-interface=vlan832-wan protocol=udp src-port=546
/ipv6 firewall mangle
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-priority=6 passthrough=yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=48 passthrough=yes protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-priority=6 passthrough=yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=48 passthrough=yes protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - COS to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-priority=6 passthrough=yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=48 passthrough=yes protocol=icmpv6
add action=accept chain=postrouting-wan-icmpv6 comment="Default accept (postrouting-wan-icmpv6)"
/ipv6 firewall mangle
add action=set-priority chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - COS to 6" new-priority=6 passthrough=yes
add action=change-dscp chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - DSCP to 6" new-dscp=48 passthrough=yes
add action=accept chain=postrouting-wan-dhcpv6 comment="Default accept (postrouting-wan-dhcpv6)"
Le CODE 90 IPV4 doit etre pareil que le code 11 IPV6.
La livebox utilise exactement le meme pour IPV4 et IPV6 en meme temps.
option dhcp6.client-id code 1 = string;
option dhcp6.auth code 11 = string;
option dhcp6.userclass code 15 = string;
option dhcp6.vendorclass code 16 = string;
option dhcp6.canalretour code 17 = string;
lease-id-format hex;
#Replace eth0 with your external interface (VLAN must be 832 for Orange)
interface "eth0.832" {
# 1
send dhcp-client-identifier 1::AA:BB:C:DD:EE:FF;
send dhcp6.client-id 00:03:00:01::AA:BB:C:DD:EE:FF;
# 11
# fti/ login / pass
# https://jsfiddle.net/kgersen/3mnsc6wy/
send dhcp6.auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:05:58:(etc);
# 15 "+FSVDSL_livebox.Internet.softathome.livebox4"
send dhcp6.userclass 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;
# 16 "sagem"
send dhcp6.vendorclass 00:00:04:0e:00:05:73:61:67:65:6d;
# 17 "XIPV6_REQUESTED"
# vendor specific information (option 17): entreprise id "Orange" 4 octets 00000558 + 2 octets option code 0006 + 14 octets Option data: 495056365f524551554553544544 ("IPV6_REQUESTED")
send dhcp6.vendor-opts 00:00:05:58:00:06:00:0e:49:50:56:36:5f:52:45:51:55:45:53:54:45:44;
}
request dhcp6.client-id, dhcp6.auth, dhcp6.userclass, dhcp6.vendorclass, dhcp6.vendor-opts, dhcp6.canalretour;
Merci pour la clarification, pourquoi avoir utilisé postrouting plutot que output ?
Par habitude. On peut faire la modification de la COS et du DSCP soit dans les chains mangle postrouting ou mangle output.
https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS (https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS)
Code: [Sélectionner]/ip firewall mangle
add action=change-dscp chain=postrouting comment="Orange - DHCPv4 - DSCP to 6" dst-port=67 new-dscp=48 out-interface=vlan832-wan passthrough=yes protocol=udp src-port=68Code: [Sélectionner]/ipv6 firewall mangle
add action=jump chain=postrouting comment="Jump to postrouting-wan-icmpv6" dst-address=fe00::/7 jump-target=postrouting-wan-icmpv6 out-interface=vlan832-wan protocol=icmpv6
add action=jump chain=postrouting comment="Jump to postrouting-wan-dhcpv6" dst-address=ff00::/8 dst-port=547 jump-target=postrouting-wan-dhcpv6 out-interface=vlan832-wan protocol=udp src-port=546Code: [Sélectionner]/ipv6 firewall mangle
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-priority=6 passthrough=yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 136 - NA) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=136:0-255 new-dscp=48 passthrough=yes protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - COS to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-priority=6 passthrough=yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 135 - NS) - DSCP to 6" dst-address=fe80::ba0:bab/128 icmp-options=135:0-255 new-dscp=48 passthrough=yes protocol=icmpv6
add action=set-priority chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - COS to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-priority=6 passthrough=yes protocol=icmpv6
add action=change-dscp chain=postrouting-wan-icmpv6 comment="Orange - icmpv6 (type 133 - RS) - DSCP to 6" dst-address=ff00::/8 icmp-options=133:0-255 new-dscp=48 passthrough=yes protocol=icmpv6
add action=accept chain=postrouting-wan-icmpv6 comment="Default accept (postrouting-wan-icmpv6)"Code: [Sélectionner]/ipv6 firewall mangle
add action=set-priority chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - COS to 6" new-priority=6 passthrough=yes
add action=change-dscp chain=postrouting-wan-dhcpv6 comment="Orange - DHCPv6 - DSCP to 6" new-dscp=48 passthrough=yes
add action=accept chain=postrouting-wan-dhcpv6 comment="Default accept (postrouting-wan-dhcpv6)"
Les régles mangle sont appliqués sur ton CCR2004 ?
Hello !
En train de tenter de mettre à jour tant bien que mal ma config (sur EdgeRouter Lite)...
Que en dhcpV4, j'ai bien ajouté l'options 60 et mis à jour la 90 (directement pris sur ce qu'envoi la LB5), et j'ai aussi mis options 60 et 77.
Je pensais avoir bien mis tout ca, mais je me retrouve avec une IP en 172.16, mais j'ai aucune idée d'où trouver la réponse DHCP pour voir quel code erreur est renvoyé... tcpdump je vois rien (ça défiiiiiiiiiiiile et après arrêt il me semble rien voir d'intéressant, pas de trace d'option 125 en tout cas...), et le /Var/log/messages est pas très bavard pour ça.
Quelqu'un pour m'aiguiller où je peux trouver cette réponse ?
Hello !
En train de tenter de mettre à jour tant bien que mal ma config (sur EdgeRouter Lite)...
Que en dhcpV4, j'ai bien ajouté l'options 60 et mis à jour la 90 (directement pris sur ce qu'envoi la LB5), et j'ai aussi mis options 60 et 77.
Je pensais avoir bien mis tout ca, mais je me retrouve avec une IP en 172.16, mais j'ai aucune idée d'où trouver la réponse DHCP pour voir quel code erreur est renvoyé... tcpdump je vois rien (ça défiiiiiiiiiiiile et après arrêt il me semble rien voir d'intéressant, pas de trace d'option 125 en tout cas...), et le /Var/log/messages est pas très bavard pour ça.
Quelqu'un pour m'aiguiller où je peux trouver cette réponse ?
set interfaces ethernet eth3 mac '<adresse MAC Livebox>'
set interfaces ethernet eth3 vif 832 dhcp-options client-option 'send vendor-class-identifier "sagem";'
set interfaces ethernet eth3 vif 832 dhcp-options client-option 'send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox4";'
set interfaces ethernet eth3 vif 832 dhcp-options client-option 'send rfc3118-auth <chaine longue https://jsfiddle.net/kgersen/3mnsc6wy/>;'
set interfaces ethernet eth3 vif 832 dhcp-options client-option 'send dhcp-client-identifier 1:<adresse MAC livebox>;'
set interfaces ethernet eth3 vif 832 dhcp-options 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;'
set interfaces ethernet eth3 vif 832 dhcp-options global-option 'option rfc3118-auth code 90 = string;'
/ip/dhcp-client/option/set [find where code="90"] value="0x00" ; /import WIP-MTK-generateOrangeAuth.rsc{ /ip/dhcp-client/option/set [find where code="90"] value="0x00" ; /import WIP-MTK-generateOrangeAuth.rsc }ne fait rien!
Télépathie ou incantations dans les bois, je laisserais le mystère planer 8)
Oui j'ai bien le client modifié.
Le temps de se vider l'esprit devant un bon déjeuner, et l'explication m'est apparue d'un coup : j'avais oublié le 01 devant la MAC, et en plus j'avais englobé le tout dans des quotes bien grasses.
Une fois corrigé, ip accrochée direct !
Au final de légers changements seulement. Faudra que je vois pour le côté dynamique de la 90 un de ces 4, et pour l'ipv6 aussi. J'ai un ERL de backup, faudra que je m'amuse avec (mon main est en 1.10.5, et j'aime pas mettre à jour inutilement des trucs qui marchent ;D)
Merci :)
Bonjour à tous,
Migration cette semaine : baux IPv4&6 de sept jours, en IPv6 retour de l'option 17 donc aucun doute sur ce point.
Ce n'est pas un problème de cos6 (inutile chez moi, pour le moment, mais les règles sont prêtes).
J'ai un doute, à savoir pourquoi la COS6 ne serait pas obligatoire si le BNG ou tu es rataché a déjà migré ?
Après tout peut être? @levieuxatorange peut-il nous confirmer si cette situation est possible?
j'ai testé ton script et ça marche bien! Merci beaucoup ;)@proap
J'ai juste un bug que je n'arrive pas à résoudre. Quand j'execute le script à la main, tout marche bien. Mais quand je mets les scripts dans les clients dhcp, en ipv6 ça fonctionne comme prévu mais en ipv4 il ne cycle pas l'option 90. Pourtant il s'agit d'un copier-coller du même script... Ca me tourne la tête!
j'ai fait une petit modification dans ton script@perl
Il faut que l'option 90 et 11 soit identique ( du moins la livebox utilise comme cela )
Concernant le CHAP challenge et idéalement le changer à chaque cycle complet DHCP quand on change le TransactionID DHCP4/6 (voir RFC)Les transactions des deux stacks (quand elles sont simultanées) devraient-elles portent le même TransactionID ?
En passant, quitte à se rapprocher de ce que fait la LB "au bit près",
dans les conversations liées au DSCP un point crucial est oublié (sauf si j'ai lu trop vite) :
Remise en DSCP=0 de tout le trafic montant (excepté ce qui doit être en DSCP=48)
Désolé de me re-citer :
https://lafibre.info/remplacer-livebox/ip-qos-sur-reseau-orange
@levieuxatorange, sauf si cela a évolué ?
A mon sens l'impact est bien plus immédiat et concret qu'un hypothétique contrôle de la valeur DSCP en phase avec la COS ;)
Bonjour à tous,
Migration cette semaine : baux IPv4&6 de sept jours, en IPv6 retour de l'option 17 donc aucun doute sur ce point. Ayant assidûment suivi ce fil pas de problèmes majeurs. Au reboot du CHR 7.7rc4 sur Proxmox tout est ok : IPv4, IPv6, télévision, téléphone... Juste un problème agaçant : le renew en IPv6 me renvoie une IPv6 de parcage, pas de problème en IPv4 (reboot, release et renew OK) Ce plantage du renew IPv6 me fait perdre l'IPv4, situation assez proche de celle décrite par @alaunay. Seule solution pour le moment un reboot toutes les 24 heures à 6h00 via le Scheduler, le t1 IPv6 est variable mais a une valeur approximative de 24h00 donc cette solution, que j'espère temporaire, est fonctionnelle mais frustrante ! Ce n'est pas un problème de cos6 (inutile chez moi, pour le moment, mais les règles sont prêtes) ni un problème de firewall IPv6 (le temps d'un test j'ai joué open bar...) Je suis donc à court d'idées et toute suggestion est la bienvenue...
Faut pas oublier l'option 61 (clientid) qui est devenu obligatoire.
il te faut donc:
option 60 vendor-class-identifier
option 61 clientid
option 77 userclass
option 90 authsend
Bonjour,
Pourrais-tu mettre tes chaines de connexion ainsi que les options etc que je puisse comparer avec les miennes ?
Car je ne sais pas où rajouter les options 60, 61 et 77. Faut-il les rajouter dans le Send Options ? Ou dans le Request option ? Ou bien les deux ?
Aussi, faut-il patcher le fichier DHCP et DHCP6 ? (pfsense 2.6).
Merci beaucoup pour ton aide.
Voici mes chaines, et ça ne fonctionne pas :
Création des VLAN 832, 838 et 840
Le VLAN832 est affecté au WAN
Send Options de pfSense :
dhcp-class-identifier "sagem",user-class "+FSVDSL_livebox.Internet.softathome.Livebox5",option-90 MaChaineDeLoption90, dhcp-client-identifier 01:AdresseMACdeLaBOX,option-15,option-120,option-125
Request options :
subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search,routers,domain-name-servers,option-90,option-15,option-120,option-125
Option modifiers :
vlan-pcp 6
Send Option DHCP6
ia-pd 0,raw-option 6 00:0b:00:1a1: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:34,raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d,raw-option 11 MaChaineOption90,raw-option 1 00:03:00:01:AdresseMACdeLaBOX
Tu penses que mes chaines sont bonnes ? en dehors de ce que tu mentionnes ? (Je vais tester, mais j'ai une livebox 5 à l'origine)
Car il manque les options :
option 60 vendor-class-identifier
option 61 clientid
option 77 userclass
option 90 authsend
Bonjour,
Pourrais-tu mettre tes chaines de connexion ainsi que les options etc que je puisse comparer avec les miennes ?
Car je ne sais pas où rajouter les options 60, 61 et 77. Faut-il les rajouter dans le Send Options ? Ou dans le Request option ? Ou bien les deux ?
dhcpv4-client options:
[admin@MikroTik] >
/ip dhcp-client option add code=60 name=vendor-class value=0x736167656d
/ip dhcp-client option add code=61 name=clientid value=0x0144A6xxxxxxxx (xxxxxxxx = fin mac adress LB4)
/ip dhcp-client option add code=77 name=user-class value=0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
/ip dhcp-client option add code=90 name=authentication value=0x00000000000000000000001A0900000558010341010D6674692F (+88 caracters)
[admin@MikroTik] >
dhcpv4-client:
/ip dhcp-client add interface=bridge-wan dhcp-options=vendor-class,clientid,user-class,authentication add-default-route=yes default-route-distance=1 use-peer-dns=yes use-peer-ntp=yes disabled=no
bridge filter:
/interface bridge filter add chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832 mac-protocol=ip src-port=68 dst-port=67 ip-protocol=udp log=yes log-prefix="Set CoS6 on DHCP4 request"
/interface bridge filter add chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832 mac-protocol=arp log=yes log-prefix="Set CoS6 for Orange ARP"
Bonjour jojo86,
Ci-dessous ce que j'envoie avec mon router Mikrotik avec ONT inséré dans le port SFP du routeur (je ne suis donc pas sous Pfsense).
Cela dit les options à envoyer sont les mêmes, à toi de les adapter pour Pfsense.Code: [Sélectionner]dhcpv4-client options:
[admin@MikroTik] >
/ip dhcp-client option add code=60 name=vendor-class value=0x736167656d
/ip dhcp-client option add code=61 name=clientid value=0x0144A6xxxxxxxx (xxxxxxxx = fin mac adress LB4)
/ip dhcp-client option add code=77 name=user-class value=0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
/ip dhcp-client option add code=90 name=authentication value=0x00000000000000000000001A0900000558010341010D6674692F (+88 caracters)
[admin@MikroTik] >
dhcpv4-client:
/ip dhcp-client add interface=bridge-wan dhcp-options=vendor-class,clientid,user-class,authentication add-default-route=yes default-route-distance=1 use-peer-dns=yes use-peer-ntp=yes disabled=no
bridge filter:
/interface bridge filter add chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832 mac-protocol=ip src-port=68 dst-port=67 ip-protocol=udp log=yes log-prefix="Set CoS6 on DHCP4 request"
/interface bridge filter add chain=output action=set-priority new-priority=6 passthrough=yes out-interface=vlan832 mac-protocol=arp log=yes log-prefix="Set CoS6 for Orange ARP"
• Pour ce qui te concerne focalise toi sur le contenu des options (60,61,77,90). Quel que soit le routeur, ce contenu doit être parfait.
• La rubrique dhcpv4-client est la création du client dhcpv4 sur mon routeur. C'est donc ce que mon client dhcpv4 ENVOIE au BNG → dhcp serveur de orange.
• La rubrique bridge filter ne doit pas te concerner car avec Pfsense je suppose que tu gères la priorité Cos6 autrement que par un bridge.
Bien à toi
Yann
Je me suis couché à 3h30, mais ca y est, j’ai réussi à obtenir une ip publique valide!!!!• Il va donc falloir que la communauté mette en place un service de nuit. ;)
Si j’ai bien compris, je vais devoir ajouter un script pour gérer le renouvellement avec une nouvelle chaine option 90? Pouvez-vous me le confirmer ?• Pas obligatoire pour l'instant, mais il faudra quand même le prévoir pour l'avenir. Quand au délai, pour l'instant, personne ne le sait vraiment.
Pas certain que ceci fonctionne : "+FSVDSL_livebox.Internet.softathome.Livebox5"Pour le coup si ça fonctionne, enfin si on s'est vu attribuer une LB5 je suppose.
Essaye ça "+FSVDSL_livebox.Internet.softathome.Livebox4"
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 client-identifier 01:xx:xx:xx:xx:xx:xx;"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox5";"
client-option "send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:1a:09:00:00:bla:bla:bla:bla:etc:etc:etc;"
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 vendor-class-identifier code 60 = string;"
global-option "option client-identifier code 61 = string;"
global-option "option user-class code 77 = string;"
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
}
}
}
}
OPTION 15 (user class) COMPLET => FSVDSL_livebox.Internet.softathome.Livebox5
00:0f:00:2d: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:35
USER CLASS DATA SEUL (que la chaine "FSVDS...")
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:35002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835
Je suppose que oui. J'ai rendu ma LB3 briquée mercredi, et du coup sur cette chaîne j'ai juste changé le chiffre à la fin (et c'est bien ce qu'envoi la LB5, vérifié sur wireshark et sur le soft livebox info).
J'utilise pas l'ipV6, mais comme j'ai tout noté pour me faire gagner du temps "le jour où", voilà ce que j'ai noté pour l'option 15 sur wireshark :Code: [Sélectionner]OPTION 15 (user class) COMPLET => FSVDSL_livebox.Internet.softathome.Livebox5
00:0f:00:2d: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:35
USER CLASS DATA SEUL (que la chaine "FSVDS...")
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:35
Côté soft livebox info, il avait ceci :Code: [Sélectionner]002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835
DONNEES DHCP V4
dhcpstatus : Bound
IPRouters : 86.245.x.x
DHCPServer : 80.10.x.x
LeaseTime : 259200 = 72h 00min 00sec
LeaseTimeRemaining : 192375 = 53h 26min 15sec
DSCPMark : 48
PriorityMark : 6
CheckAuthentication : True
AuthenticationInformation: dhcpliveboxfr250
ResetOnPhysDownTimeout : 20
SentOption : 60,61,77,90
SentOption 60 : 736167656d #Sagem
SentOption 61 : 01MACFREEBOX #( ne pas oublié le 01
SentOption 77 : 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835 #"+FSVDSL_livebox.Interneathome.Livebox5" Attention certain client ajoute le + eux meme ( uniquity )
SentOption 90 : 00000000000000000000001a0900000558010341010d6674692fftx/LOGINLOGIN3c12SALTSALTSALTSALTSALTSALTSALTSALT0313XXHASHHASHHASHHASHHASHASHHASHHASHH
ReqOption : 1,3,6,15,28,51,58,59,90,119,120,125
DONNEES DHCP V6
dhcpstatus : Bound
DUID : 00:03:00:01:8c:fd:de:xx:xx:xx #DUID = 00:03:00:01:MACADDRESS Attention certain client ( mikrokit initialise au premier lancement du dhcpclient bien avoir fake addresse mac de l'interface avant )
CheckAuthentication : True
AuthenticationInfo : dhcpliveboxfr250
ResetOnPhysDownTimeout : 20
SentOption : 11,15,16,17
SentOption 11 : 00000000000000000000001a0900000558010341010d6674692fftx/LOGINLOGIN3c12SALTSALTSALTSALTSALTSALTSALTSALT0313XXHASHHASHHASHHASHHASHASHHASHHASHH
SentOption 15 : 002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835 # "+FSVDSL_livebox.Interneathome.Livebox5"
SentOption 16 : 0000040e0005736167656d # "\016\000\005sagem" ( ne mettre que "sagem" dans l'option )
SentOption 17 : 000005580006000e495056365f524551554553544544 # " \006\000\016IPV6_REQUESTED"
ReceivedOption : 1,2,11,17,23,24,25
Si cela peut aider voici ce que me donne la MIB sur la livebox
La chose qui me surprend et que option 15 IPV6 versus 77 IPV4 a un 0x00 en plus devant
oui c'est curieux mais ca fonctionne. Pour ceux qui ont été migré et pour qui tout fonctionne, vous avez quoi comme chaine exacte svp ?
user-class: 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
user-class: 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
Si cela peut aider voici ce que me donne la MIB sur la livebox
La chose qui me surprend et que option 15 IPV6 versus 77 IPV4 a un 0x00 en plus devant
D'ailleur sur mikrotik si je mets pas les 00 en plus devant. Wireshark me detect une erreur dans l'option userclass
ce n'est pas un sniff .
C'est les information donnée par livebox info.
Option 1 : Client identifier = DUID
Option: Client Identifier (1) Value: 0003000144a6xxxxxxxx
@proap
Es-tu certain de n'avoir qu'une seule option code=90 dans la liste /ip/dhcp-client/option ?
En l'état le script ne procède au remplacement que s'il ne trouve qu'une seule occurence portant ce code.
(même si les autres ne sont pas 0x00)
/ip/dhcp-client/option/set [find where code="90"] value="0x00" ; /import WIP-MTK-generateOrangeAuth.rsc{ /ip/dhcp-client/option/set [find where code="90"] value="0x00" }Mais la mise à '0' du champ 90 via le script dans le dhcp-client ne fait rien!:Pour être franc je n'ai essayé qu'en IPv6 ;)Code: [Sélectionner]{ /ip/dhcp-client/option/set [find where code="90"] value="0x00" }le problème n'est pas au niveau du script. ;)
:delay 1en tête du script WIP-MTK-generateOrangeAuth.rsc ?
Il faut que authentification soit identique.Non.
Non.
Il est à noter que en cas de non respect de la cohérence (soit entre les deux protocoles, soit au sein d'un même protocole) la ligne sera déconnectée.
La ligne => les 2 stacks v4 et v6
Concrètement, ce qui va changer (et qui peut vous impacter) :
- le contrôle du mot de passe dans l'option 90 (DHVPv4) et 11 (DHCPv6) va être total.Il est à noter que en cas de non respect de la cohérence (soit entre les deux protocoles, soit au sein d'un même protocole) la ligne sera déconnectée.
La ligne => les 2 stacks v4 et v6
Bonjour,
Je viens d'essayer avec une option 90 différente de l'option 11 et j'obtiens bien une IPv4 et une IPv6 au reboot du routeur.
Et le message de @levieuxatorange est pour moi aussi tres claire 90 == 11 ( IPV4 == IPV6 )Oui, il est écrit quoi ? Le contrôle du mot de passe, donc pas besoin d'avoir des options identiques du moment que le mot de passe est hashé correctement.Code: [Sélectionner]Concrètement, ce qui va changer (et qui peut vous impacter) :
- le contrôle du mot de passe dans l'option 90 (DHVPv4) et 11 (DHCPv6) va être total.
/interface bridge
add name=bridge protocol-mode=none
add fast-forward=no name=orange-832 protocol-mode=none
/interface vlan
add interface=ether1 name=VLAN832 vlan-id=832
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip dhcp-client option
add code=61 name=clientid value=0x01LEMACDELAFREEBOX
add code=60 name=vendor-class-identifier value=0x736167656d
add code=77 name=userclass value="0x2b46535644534c5f6c697665626f782e496e746572\
6e65742e736f66746174686f6d652e4c697665626f7833"
add code=90 name=authsend value="0x0000000000000000000000...VotreIDLONG"
/interface bridge filter
add action=set-priority chain=output dst-port=67 ip-protocol=udp log=yes \
log-prefix="Set CoS6 on DHCP IPv4 request" mac-protocol=ip new-priority=6 \
out-interface=VLAN832 passthrough=yes
add action=set-priority chain=output dst-port=67 ip-protocol=udp \
mac-protocol=ip new-priority=6 out-interface=VLAN832 passthrough=yes \
src-port=68
add action=set-priority chain=output disabled=yes mac-protocol=ipv6 \
new-priority=6 out-interface=VLAN832 passthrough=yes
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
add bridge=bridge interface=ether4
add bridge=bridge interface=ether5
add bridge=orange-832 interface=VLAN832
/interface list member
add comment=defconf interface=ether1 list=WAN
add interface=bridge list=LAN
/ip dhcp-client
add dhcp-options=authsend,clientid,hostname,userclass interface=orange-832
La notion de "IP Fixe" est contractuelle : offre PRO ou option à 17€ / Mois (plus dispo GP depuis ... je sais même plus quand ...)
La l'IP qui ne change pas c'est quelle est "préférentielle" et tant que le réseau n'en n'a pas eu besoin, elle change pas ....
Dans le nouveau système, pour changer d'IP, il faut aller sur l'interface web du selfcare dans les pages de l'espace client orange.fr
Point important : dans le nouveau système, pour des questions CNIL entre autre, l'IP changera une fois par an minimum ...
Et du coup c'est dépendant de l'option 90/11 ou pas ? Ou elle change à chaque reboot et c'est géré autrement ?Sur l'ancien système cela change sur un release.
AH ! dommage... on peut pas demander une exception ? Et pour l'ipv6 pareil je suppose ?IPv6 pareil et non pas possible :)
D'autre part, aurais-tu des infos sur la fonction délégation de préfixe de la LB, savoir s'il est prévu un correctif pour pouvoir demander plus qu'un /64 par équipement ? Voir le préfixe entier moins le préfixe réservé par la box ? (RFC 6603)C'est pas une correction, mais une demande d'évolution
C'est pas une correction, mais une demande d'évolution
Je l'ai faite coté Mkt (ainsi qu'une amélioration de l'ouverture des ports en Ipv6) suivant ce que j'ai lu dans ce forum
bonjour à tous,
le jeudi 16 mars, mon client dhcp6 (dhclient) m'a envoyé un événement avec reason=DEPREF6 suivi immédiatement d'un autre événement avec reason=EXPIRE6
Dans les logs cela donne:Code: [Sélectionner]Mar 16 18:21:07 ipc logger[188439]: ipv6-setup is called, reason=DEPREF6
Mar 16 18:21:07 ipc dhclient[1308]: PRC: Prefix 2a01:xxxx:xxxx:xxxx::/56 depreferred.
Mar 16 18:21:07 ipc logger[188448]: ipv6-setup is called, reason=EXPIRE6
évidemment j'ai perdu ma connexion IPV6 car mon script "ipv6-setup" n'était pas très clean pour gérer ces événements qui, je pensais, n'arrivaient jamais.
Cela vous arrive ou pas ? en temps normal, je ne reçois que des RENEW6....
Salut,
Je n'ai pas compris cette phrase. Pourrais-tu donner plus d'infos stp ?
Il est possible de demander plus d'un seul /64 en delegation ? si oui comment ?
De même pour l'ouverture des ports en ipv6, que cela signifie t-il ?
Merci bcp :)
J'ai remonté 2 choses :
- avec une délégation lpus large qu'un /64 (un /60 ou plusieurs /64)
- un firewall IPv6 avec une meilleur stabilité de détection du next HOP pour l'ouverture du flux
On aurait un nombre certain d'entre vous à qui cela suffirait pour avoir un réseau en IPv6 à votre main et garder la LB6 sans plus d'effort
LeVieux
IPv6 pareil et non pas possible :)Ce qui explique donc que sur l'une de nos lignes, le préfixe IPv6 ait changé quelques jours après la migration.
Sur l'ancien système cela change sur un release.
Sur la nouveau système cela sur demande explicite dans l'espace client (un simple release ne change plus)
Ou dans les deux cas si le réseau en a besoin
IPv6 pareil et non pas possible :)
C'est pas une correction, mais une demande d'évolution
Je l'ai faite coté Mkt (ainsi qu'une amélioration de l'ouverture des ports en Ipv6) suivant ce que j'ai lu dans ce forum
Question, si on force via le selfcare un changement d'IP,Bonjour
- cela change-t-il aussi le préfixe IPv6 ?
- la période de ~ 1 an est-elle remise à zéro par cette action ?
Quitte à devoir changer, plutôt l'anticiper que le subir :)
Oui cela change IPv4 et IPv6Bonjour, et merci pour cette information.
et Oui, le timer de changement "de force" est remis à zéro
Pour être franc je n'ai essayé qu'en IPv6 ;)
A tout hasard essayer d'ajouterCode: [Sélectionner]:delay 1en tête du script WIP-MTK-generateOrangeAuth.rsc ?
{:log info \"DHCP client renewed:\"} fonctionne lors d'un renew. { /ip/dhcp-client/option/set [find where code="90"] value="0x00"} ne fait rien! ;D
ça ne fait rien :(
c'est évident que j'ai un bug sur mon installation routerOS 7.8. Je vais essayer de re-installer pour voir.
Le plus etrange est queCode: [Sélectionner]{:log info \"DHCP client renewed:\"}fonctionne lors d'un renew.
MaisCode: [Sélectionner]{ /ip/dhcp-client/option/set [find where code="90"] value="0x00"}ne fait rien! ;D
/ip/client/dhcp-client/edit <interface> script
il existe chez openWRT et ubiquiti du moins (mais ça semble lié de base à iptables) une notation spécifique qui permet de ne prendre en charge que le suffixe : ::6666:b3ff:fe47:e1b9/::ffff:ffff:ffff:ffffOui, c'est ce que j'utilisais depuis plusieurs années sur mon ERL puis mon ER4. D'autant plus que j'utilise un préfixe ULA en plus du GUA et que du coup ça permet d'avoir une seule règle par service exposé. Malheureusement non supporté par le firewall IPv6 Mikrotik. Donc du coup je mets mes adresses GUA dans des address-list avec un commentaire spécifique pour les distinguer, et dans le script appelé par le client DHCP6-PD à chaque lease, je parcours les address-list et met à jour les préfixe des addresses ayant ce commentaire.
Oui, c'est ce que j'utilisais depuis plusieurs années sur mon ERL puis mon ER4. D'autant plus que j'utilise un préfixe ULA en plus du GUA et que du coup ça permet d'avoir une seule règle par service exposé. Malheureusement non supporté par le firewall IPv6 Mikrotik. Donc du coup je mets mes adresses GUA dans des address-list avec un commentaire spécifique pour les distinguer, et dans le script appelé par le client DHCP6-PD à chaque lease, je parcours les address-list et met à jour les préfixe des addresses ayant ce commentaire.
Enfin, plutôt c'est ce que je vais faire, il faut que j'écrive le script (mais ça devrait aller, je commence à maitriser, j'ai déjà fait le script pour mettre à jour les enregistrements A et AAAA de mes zones hébergées par Cloudflare), c'est la dernière chose qu'il me reste à faire avant de pouvoir remplacer l'ER4 par mon CCR2004... ;D
Donc du coup je mets mes adresses GUA dans des address-list avec un commentaire spécifique pour les distinguer, et dans le script appelé par le client DHCP6-PD à chaque lease, je parcours les address-list et met à jour les préfixe des addresses ayant ce commentaire.Bien vu! J'avais posté (sur une de tes questions) mon script dans cette idée, couplé au watchdog, mais le mien ne va pas jusque là.
Bien vu! J'avais posté (sur une de tes questions) mon script dans cette idée, couplé au watchdog, mais le mien ne va pas jusque là.
https://lafibre.info/remplacer-livebox/guide-de-connexion-fibre-directement-sur-un-routeur-voire-meme-en-2gbps/msg995130/#msg995130
Je suis preneur également de cette partie :)
# DHCP6-PD lease script
:local PdValid $"pd-valid"
:local PdPrefix $"pd-prefix"
:if ([ :typeof $PdPrefix ] = "nothing") do={
:log error "[DHCP6-PD-CLIENT] This script is a DHCP6 lease script"
:error "[DHCP6-PD-CLIENT] This script is a DHCP6 lease script"
}
:local Config {
{name="V66-DATA-GUA";addr="::66:0:0:0:1"};
{name="V68-TVIP-GUA";addr="::68:0:0:0:1"};
{name="V69-MGNT-GUA";addr="::69:0:0:0:1"};
{name="V70-DMZ-GUA";addr="::70:0:0:0:1"};
}
# Update interfaces GUA address
foreach C in=$Config do={
:local IdAddr [/ipv6 address find comment=($C->"name")]
:local Interface [/ipv6 address get $IdAddr interface]
:local Disabled [/ipv6 address get $IdAddr disabled]
:local OldAddr [/ipv6 address get $IdAddr address]
:local OldPrefix (([:toip6 [:pick $OldAddr 0 [:find $OldAddr "/"]]] & ffff:ffff:ffff:ff00::)."/56")
:if ($PdValid = 1) do={
:local NewPrefix [:toip6 [:pick $PdPrefix 0 [:find $PdPrefix "/"]]]
:local NewAddr (($NewPrefix | [:toip6 ($C->"addr")])."/64")
:if ($OldAddr != $NewAddr || $Disabled = true) do={
:log info ($Interface.": new prefix: ".$NewPrefix)
/ipv6 address set $IdAddr address=$NewAddr disabled=no
}
} else={
/ipv6 address set $IdAddr disabled=yes
:log info ($Interface.": expired prefix: ".$OldPrefix)
}
}
# Update address lists
:if ($PdValid = 1) do={
:local NewPrefix [:toip6 [:pick $PdPrefix 0 [:find $PdPrefix "/"]]]
foreach ListEntry in=[/ipv6/firewall/address-list/find where comment~"GUA"] do={
:local ListEntryVal [/ipv6/firewall/address-list get $ListEntry]
:local OldAddrIP [:toip6 [:pick ($ListEntryVal->"address") 0 [:find ($ListEntryVal->"address") "/"]]]
:local Suffix ($OldAddrIP & ::ff:ffff:ffff:ffff:ffff)
:local NewAddrIP ($NewPrefix | $Suffix)
if ($OldAddrIP != $NewAddr) do={
/ipv6/firewall/address-list set address=($NewAddrIP."/128") $ListEntry
}
}
}
Remarques:Merci pour le partage de ton script.
Pour ma part, je préfère le tout-en-un (type watchdog), je vais compléter le mien pour inclure la mise à jour des address-lists.
Quand tu dis watchdog, tu sous-entends un script qui tourne uniquement via le scheduler c'est bien cela ?Oui. J'ai mis un intervalle de 5mn, ce qui me semble un bon compromis.
Si oui, ca veut dire que quand le dhcp client récupère un nouveau prefix (si dynamique), alors entre cet instant et le prochain schedule, tu n'es pas à jour ?
Il faut attendre le prochain schedule pour l'execution du script.
/ipv6/dhcp-client/set orange-dhcp-v6 script="{ /system/script/run watchdog-ipv6 }"
Oui. J'ai mis un intervalle de 5mn, ce qui me semble un bon compromis.
Et en fait, tout en gardant ce principe, on pourrait faire :Code: [Sélectionner]/ipv6/dhcp-client/set orange-dhcp-v6 script="{ /system/script/run watchdog-ipv6 }"
Il semblerait que les requêtes NAK du serveur DHCP de orange ne sont pas authentifiées, ce que qui fait que certains client (comme dhcpcd) ignore ce NAK.
Du coup avec ma config, je perdais la connectivité au bout de ~24h. J'ai du ajouter noauthrequired, et maintenant ça a l'air de bien tenir. Si ça peut servir à d'autres...
Bonjour,
Oui, je confirme, je suis en IPV4
Donc à Montauban (82) , C'est IPV4 dans mon Quartier .
option dhcp6.authentication code 11 = string;
subnet6 2001:db8:0:100::/64 {
option dhcp6.name-servers vos-DNS;
option dhcp6.domain-search "livebox.lan";
option dhcp6.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;
prefix6 2001:db8:0:100:: 2001:db8:0:f00:: /56;
}
Je me demande si les LB auraient demandé un redémarrage.Bonjour
Par contre, concernant la délégation de préfixe, je ne sais pas si je suis teubé ou juste fatigué mais je n'arrive pas à distribuer plus que des /64. Il me gueule dessus à chaque fois en disant que le masque est trop court.
Disons que mon préfixe est 2a01:dd78:dda:1200::/56 et que je prends le premier /60 pour distribuer des /62 je mets donc : prefix6 2a01:dd78:0dda:1200:: 2a01:dd78:0dda:120f:: /62 et ça ne fonctionne pas. Ça doit être évident, mais je vois pas.
Si c'est pas indiscret, vous utilisez quels modèles de routeurs pour les BNG ? Sur les MAC j'ai vu passer du nokia, mais je sais pas si c'est fiable.
De même avec toutes les options pas courantes, j'imagine que le firmware est custom spécialement pour orange, non ?
Bonjour
Petit rappel à tous, le contrôle des paramètres User Class est CASE SENSITIVE
Donc pour tous, mettre
FSVDSL_livebox.Internet.softathome.Livebox6
comme UserClass
En respectant BIEN les majuscule / minuscule
Il n'y a pas de contrôle entre votre fti et votre firmware ...
LeVieux
Firmware 100% standard, c'est pas le BNG qui vérifie le contenu spécifique, il sait le forward vers le point qui assure ce contrôle (et plein d'autres choses)
Pas le droit de répondre sur le fournisseur :)
LeVieux
Salut,
Du coup, pour l'option 15 en ipv6, la chaine correspondante est : "002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836", c'est bien cela ?
merci
Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
User Class Length: 43
User Class Data: 46535644534c5f6c697665626f782e496e7465726e65742e…
0000 4d 2c 2b 46 53 56 44 53 4c 5f 6c 69 76 65 62 6f M,+FSVDSL_livebo
0010 78 2e 49 6e 74 65 72 6e 65 74 2e 73 6f 66 74 61 x.Internet.softa
0020 74 68 6f 6d 65 2e 4c 69 76 65 62 6f 78 36 thome.Livebox6
User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c697665626f782e496e7465726e65…
0000 00 0f 00 2d 00 2b 46 53 56 44 53 4c 5f 6c 69 76 ...-.+FSVDSL_liv
0010 65 62 6f 78 2e 49 6e 74 65 72 6e 65 74 2e 73 6f ebox.Internet.so
0020 66 74 61 74 68 6f 6d 65 2e 4c 69 76 65 62 6f 78 ftathome.Livebox
0030 36 6
Pris du dump de ma LB6 ( j'ai les équivalents sur tous mes modèles de boxe, prenez la LB6 cela durera plus longtemps)
En v4 :Code: [Sélectionner]Option: (77) User Class Information
Length: 44
Instance of User Class: [0]
User Class Length: 43
User Class Data: 46535644534c5f6c697665626f782e496e7465726e65742e…
0000 4d 2c 2b 46 53 56 44 53 4c 5f 6c 69 76 65 62 6f M,+FSVDSL_livebo
0010 78 2e 49 6e 74 65 72 6e 65 74 2e 73 6f 66 74 61 x.Internet.softa
0020 74 68 6f 6d 65 2e 4c 69 76 65 62 6f 78 36 thome.Livebox6
En v6 :Code: [Sélectionner]User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c697665626f782e496e7465726e65…
0000 00 0f 00 2d 00 2b 46 53 56 44 53 4c 5f 6c 69 76 ...-.+FSVDSL_liv
0010 65 62 6f 78 2e 49 6e 74 65 72 6e 65 74 2e 73 6f ebox.Internet.so
0020 66 74 61 74 68 6f 6d 65 2e 4c 69 76 65 62 6f 78 ftathome.Livebox
0030 36 6
LeVieux
J'ai remonté 2 choses :
- avec une délégation lpus large qu'un /64 (un /60 ou plusieurs /64)
- un firewall IPv6 avec une meilleur stabilité de détection du next HOP pour l'ouverture du flux
On aurait un nombre certain d'entre vous à qui cela suffirait pour avoir un réseau en IPv6 à votre main et garder la LB6 sans plus d'effort
Je sens bien la douche froide venir :(
Si c'est pas indiscret, vous utilisez quels modèles de routeurs pour les BNG ? Sur les MAC j'ai vu passer du nokia, mais je sais pas si c'est fiable.Du côté abonné, les routeurs Orange c'est essentiellement Nokia/Alu d'ailleurs le bng est certainement Nokia, bsa également mais certainement font-ils la même fonction. NE(Département) NB, NM (collecte option 3 par exemple) ,NC(région) série de Nokia/alu en général sont tout les mégaswitchs routeurs de distribution vers abonnés rbci.
De même avec toutes les options pas courantes, j'imagine que le firmware est custom spécialement pour orange, non ?
root@rockpro64:~# cat /etc/dhcp/dhcpd6.conf
default-lease-time 86400;
option dhcp6.authentication code 11 = string;
ignore declines;
# Range for clients
subnet6 2a01:cbxx:xx:4d10::/60 {
# Additional options
option dhcp6.name-servers xxx1, xxx2;
# T1, the delay before Renew
# (default is 1/2 preferred lifetime)
# (set to 1 hour)
option dhcp-renewal-time 3600;
# T2, the delay before Rebind (if Renews failed)
# (default is 3/4 preferred lifetime)
# (set to 2 hours)
option dhcp-rebinding-time 7200;
}
# Example for a fixed host address
host livebox5 {
server-duid EN 1368 "DESHAYESSUDROT";
host-identifier option dhcp6.client-id 00:03:00:01:04:e3:1a:7f:fb:50;
# Adapter la mac dans le host-identifier
fixed-address6 2a01:cbxx:xx:4d10::256;
fixed-prefix6 2a01:cbxx:xx:4d10::/60;
option dhcp6.domain-search "orange.fr";
option dhcp6.server-id 00:02:00:00:05:58:44:45:53:48:41:59:45:53:53:55:44:52:4f:54;
option dhcp6.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;
Du côté abonné, les routeurs Orange c'est essentiellement Nokia/Alu d'ailleurs le bng est certainement Nokia, bsa également mais certainement font-ils la même fonction. NE(Département) NB, NM (collecte option 3 par exemple) ,NC(région) série de Nokia/alu en général sont tout les mégaswitchs routeurs de distribution vers abonnés rbci.
Il existe probablement encore le lien vers des ''bas'' probablement en configuration final radius, les smartedge/juniper était dans le réseau avant 2020.
[...]
Hello (@Renaud07),
Si on parle bien d'un LB avec sa patte WAN connectée à ton LAN alors avec cette config serveur (isc-)dhcp j'arrive à lui assigner un préfixe ipv6 :Code: [Sélectionner]root@rockpro64:~# cat /etc/dhcp/dhcpd6.conf
default-lease-time 86400;
option dhcp6.authentication code 11 = string;
ignore declines;
# Range for clients
subnet6 2a01:cb04:94:4d10::/60 {
# Additional options
option dhcp6.name-servers xxx1, xxx2;
# T1, the delay before Renew
# (default is 1/2 preferred lifetime)
# (set to 1 hour)
option dhcp-renewal-time 3600;
# T2, the delay before Rebind (if Renews failed)
# (default is 3/4 preferred lifetime)
# (set to 2 hours)
option dhcp-rebinding-time 7200;
}
# Example for a fixed host address
host livebox5 {
server-duid EN 1368 "DESHAYESSUDROT";
host-identifier option dhcp6.client-id 00:03:00:01:04:e3:1a:7f:fb:50;
# Adapter la mac dans le host-identifier
fixed-address6 2a01:cbxx:xx:4d10::256;
fixed-prefix6 2a01:cbxx:xx:4d10::/60;
option dhcp6.domain-search "orange.fr";
option dhcp6.server-id 00:02:00:00:05:58:44:45:53:48:41:59:45:53:53:55:44:52:4f:54;
option dhcp6.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;
Solicit message from fe80::46a6:1eff:xxxx:xxxx port 546, transaction ID 0xC38D6900
Advertise PD: address 2a01:cb14:xx:xxxx::/62 to client with duid 00:03:00:01:44:a6:1e:xx:xx:xx iaid = 510438230 static
Sending Advertise to fe80::46a6:1eff:xxxx:xxxx port 546
Request message from fe80::46a6:1eff:xxxx:xxxx port 546, transaction ID 0xE9487A00
Discarding Request from fe80::46a6:1eff:xxxx:xxxx; not our server identifier (CLIENTID 00:03:00:01:44:a6:xx:xx:xx:xx, SERVERID 00:02:00:00:05:58:44:45:53:48:41:59:45:53:53:55:44:52:4f:54, server DUID 00:01:00:01:2b:bf:29:d9:b8:27:eb:ea:13:a9)
host-identifier option dhcp6.client-id 00:03:00:01:04:e3:1a:7f:fb:50En fait je me suis inspiré d'une capture entre la LB5 branchée normalement et j'ai reproduit la config côté serveur dhcp.
- As-tu bien adapté le client identifier (pour que ça matche la mac de ta LB) ?Code: [Sélectionner]host-identifier option dhcp6.client-id 00:03:00:01:04:e3:1a:7f:fb:50
- Par ailleurs, à relire ton message il faudrait sans doute aussi setté le serveur duid pour qu'il matche la mac adresse de ton interface réseau par lequel sors le dhcp)
(à tout hasard essaye aussi en commentant)
- Le server-duid EN 1368 "DESHAYESSUDROT"; est (était?) envoyé par Orange, donc je l'ai remis. Je vais essayer de retrouver une capture.
EDIT : je viens de vérifier il semble en effet que ce n'est plus renvoyé (suite à la migration ?), et la capture concernait une LB4. Tu peux sans doute l'omettre.
Prends pas de risque, utilise un autre routeur :-)
Oui cela change IPv4 et IPv6Sauf loupé de ma part, je n'ai pas trouvé cette option (forcer le chgmt des adrs IP) dans l'interface de gestion en ligne (selfcare?)
et Oui, le timer de changement "de force" est remis à zéro
En effet ça fonctionne sans server-duid et server-id que je n'avais de toute façon pas mis au départ.
Mais ma question portait plus sur comment c'est censé fonctionner si activé. Car comme dit avant, server-duid n'a pas l'air d'être utilisé si je commente server-id.
Sauf loupé de ma part, je n'ai pas trouvé cette option (forcer le chgmt des adrs IP) dans l'interface de gestion en ligne (selfcare?)Je viens en effet de trouver cette option sur un contrat Orange particulier.
...
Pour info je suis en contrat Pro (sans l'option IP fixe).
Chez Orange Pro, tu peux demander une IP Fixe gratuitement hein ;)Quand on avait ouvert nos contrats Orange Pro, la majorité en 2017/18, le tableau était assez différent,
je parle bien d'IP Fixe et pas préférentielle. (vérifié sur 2 connexions Orange Pro à plusieurs centaines de km d'écarts)
et on est bien en DHCP avec IPv4 + IPv6.
Quand on avait ouvert nos contrats Orange Pro, la majorité en 2017/18, le tableau était assez différent,Bonjour
PPPoE (avec sa MTU à 1492), IPv4 seulement, et E/S du trafic sur un POP en région parisienne.
Depuis un certain temps le DHCP(v4) semble possible en IP fixe, cependant d'après @levieuxatorange l'IPv6 n'est pas encore en place.
Tu confirmes que ça fonctionne pourtant ?
(ou alors celle-ci n'est pas encore "garantie" fixe)
Si on part sur cette option, restera donc un (petit) supplément de latence dans certains cas, vu que les IP fixes nationales sont annoncées sur Paris.
On verra bien.
- coté LB PRO, le stack DHCPv6 n'est pas encore activé.
LeVieux
Salut,Bonjour
Je ne comprends pas cette phrase.
J’ai une offre pro depuis pas mal de temps.
Avec mes routeurs tiers (Mikrotik et Archlinuxj, j’ai effectivement bien ipv4 fixe et ipv6 « fixe » ( je n’ai jamais changé de prefix).
Quand j’ai joué au début avec la LB6, il me semble que j’avais aussi un prefix ipv6, je me trompe ?
Merci
Bonjour
LB6 option PRO cela marche (j'ai un doute sur l'existence d'une LB5 option pro ???)
LB PRO 3 ou 4 (branche totalement différente de la branche LB Grand public) ce n'est pas encore activé (cela devrait être le cas dans un futur proche).
LeVieux
Bonjour
Deux choses :
- coté réseau, le DHCPv4 + IPfixe fonctionne et le DHCPv6 + prefix dynamique (préférentiel) fonctionne.
- coté LB PRO, le stack DHCPv6 n'est pas encore activé.
Par contre attention : je n'ai pas encore de notion de DHCPv6 + Préfix FIXE (au sens contractuel) dans le viseur pour une mise en prod.
Donc une offre PRO avec un routeur tier (comme vous tous ici) fonctionnera en DUAL STACK avec une IPv4 FIXE (au sens contractuelle) et un Prefix IPv6 Dynamique (même si préférentiel)
LeVieux
IPv4
userclass Code 15
000f002d002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
IPv6
userclass Code 77
000f002d002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
@levieuxatorange, je ne peux pas te dire plus merci.
Le fait que tu te penches sur notre cas, et que tu éclaires l'ombre avec la certitude tranquille de celui sait, c'est tellement rare et précieux.
Sinon, j'ai essayé tes chaines
Je me suis fait parker direct.
Je suis revenu à mes vieilles chaînes en LBv3 de mémoire
Hello,
Je pense qu'il faut utiliser :
ipv4 : 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
ipv6 : 002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
avec le dernier octet (6 ici) qui donne la version de la LB : 4 pour LB4, 5 pour LB5, 6 pour LB6, etc...
Bonjour @tous,
J'ai bien utilisé les chaines que mentiones, ci-dessus, @cyayon et... je me suis fait parker cette nuit également lors de mon reboot quotidien.
Dès que j'ai remis le 4 à la place du 6 à la fin de la chaine tout est redevenu normal.
Donc 36 (LB6) à la fin ne fonctionne pas pour moi non plus → 34 (LB4) c'est ok.
Est ce lié à certaines zones géographiques ?
Bonjour @tous,
J'ai bien utilisé les chaines que mentiones, ci-dessus, @cyayon et... je me suis fait parker cette nuit également lors de mon reboot quotidien.
Dès que j'ai remis le 4 à la place du 6 à la fin de la chaine tout est redevenu normal.
Donc 36 (LB6) à la fin ne fonctionne pas pour moi non plus → 34 (LB4) c'est ok.
Est ce lié à certaines zones géographiques ?
@levieuxatorange, je ne peux pas te dire plus merci.Bonjour
Le fait que tu te penches sur notre cas, et que tu éclaires l'ombre avec la certitude tranquille de celui sait, c'est tellement rare et précieux.
Sinon, j'ai essayé tes chaines
Je me suis fait parker direct.
Je suis revenu à mes vieilles chaînes en LBv3 de mémoire
IPv4 option 77 : 4d2c2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
IPv6 option 15 : 000f002d002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
Bonjour
Elle sont toutes pourrîtes tes chaines :)
Tu as mélangé l'encodage DHCPv4 avec l'option 77 et l'encodage DHCPv6 avec l'option 15Code: [Sélectionner]IPv4 option 77 : 4d2c2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
IPv6 option 15 : 000f002d002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
LeVieux
ipv4 : 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
ipv6 : 002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
Bonjour
Elle sont toutes pourrîtes tes chaines :)
Tu as mélangé l'encodage DHCPv4 avec l'option 77 et l'encodage DHCPv6 avec l'option 15Code: [Sélectionner]IPv4 option 77 : 4d2c2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
IPv6 option 15 : 000f002d002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
LeVieux
ipv4 (option 77) : 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
ipv6 (option 15) : 002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836
ok pour toi ?Pour le contenu des options oui.
Après attention à vos clients suivant qu'ils encodent en raw ou pas ..
LeVieux
Option 77 : 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
Option 15 : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f78340aHello,
Me concernant j'ai ceci dans les values :Code: [Sélectionner]Option 77 : 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
Option 15 : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f78340a
et ça fonctionne parfaitement me concernant après migration sur Annemasse
Option 77 : 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837
Option 15 : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7837Sur Mikrotik ?
Pourquoi l’option 15 termine par 0a ?
Ce serait possible d’essayer de terminer les 2 chaînes par 6 (au lieu de 4) et voir si ça fonctionne ?
Merci
Oui c'est un CCR2004
J'essayerai demain matin
Aucune idée de pourquoi ça se termine par 0a, le jour de la migration il a fallu que je rebranche la livebox pour en copier les chaines, celles que j'avais, bien que longues, ne fonctionnaient plus
Tiens, c'est rigolo, la Livebox 7 est reconnue.
Les deux options suivantes fonctionnent...Code: [Sélectionner]Option 77 : 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837
Option 15 : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7837
Bientôt sur le marché ?
J'ai aussi testé avec 8 et 9. Celles-ci ne fonctionnent pas.
Tu as été migré ?Oui
Oui
Sur Mikrotik ?
Pourquoi l’option 15 termine par 0a ?
Ce serait possible d’essayer de terminer les 2 chaînes par 6 (au lieu de 4) et voir si ça fonctionne ?
Merci
@cyayonMerci !
0a en hexa, c'est le caractère "vide" ou de "fin de ligne", cf. https://en.wikipedia.org/wiki/0A (https://en.wikipedia.org/wiki/0A)
Je ne serais pas étonné que le routuer de @lekr le tronque avant d'envoyer la chaîne, ce qui expliquerait pourquoi l'authentification réussi.
Dit autrement, @lekr devrait enlever ce caractère de la configuration de son router pour éviter de se prendre les pieds dans le tapis "un jour": tout ce qui suit devrait immanquablement être tronqué
Tu as bien fait un release avant de changer la chaine ?
Bonjour @tous,
@cyayon, @nonobzh, @lekr
Comment j'ai procédé → modification des 2 chaines (Mikrotik hex_s) en cours de journée soit:
option 77: 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836 (pour ipv4)
option 15: 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7836 (pour ipv6)
(je n'ai pas fait de release à ce moment là, il me restait 6 jours de bail)
• Le routeur (via le scheduler) a fait un reboot au milieu de la nuit suivante avec release et un disable des 2 client dhcp (v4 & v6) avant d'initier le reboot.
• Une fois le reboot terminé (via un ptit script déclenché par le scheduler) je réactive les 2 client dhcp (v4 & v6).
• Et c'est là que je me suis fait parker sachant que j'avais prépositionner les 2 options telle que ci-dessus la veille.
• J'ai donc dû revenir au 34 à la fin (comme le LB4 de mon offre chez orange).
Suite des investigations (pas de reboot lors des actions ci-dessous):
• ce-matin je viens de remplacer le 34 par 36 à la fin des options 77 & 15 ci-dessus.
• J'ai ensuite fait un release des 2 clients dhcp (v4 & v6) → et là ça fonctionne avec 36.
• J'ai aussi mis 37 à la fin (comme pour une évenruelle LB7) → ça fonctionne toujours après un release des 2 clients dhcp (v4 & v6).
• J'ai poussé le bouchon jusqu'à 38 et après un release des 2 clients dhcp (v4 & v6) → et... là ça ne fonctionne plus (parcage !!).
Je suis donc revenu au 36 (LB6) + release des 2 clients dhcp (v4 & v6) → retour immédiat des des 2 bounds avec bonne IP publique.
Le routeur fera un nouveau reboot cette nuit vers 1h du matin, je laisse en place le 36. On verra le résultat à la fin du reboot.
Ps: pour @lekr, oui le 0A à la fin il faut le supprimer comme le mentione @jbfavre.
@cyayon
0a en hexa, c'est le caractère "vide" ou de "fin de ligne", cf. https://en.wikipedia.org/wiki/0A (https://en.wikipedia.org/wiki/0A)
Je ne serais pas étonné que le routuer de @lekr le tronque avant d'envoyer la chaîne, ce qui expliquerait pourquoi l'authentification réussi.
Dit autrement, @lekr devrait enlever ce caractère de la configuration de son router pour éviter de se prendre les pieds dans le tapis "un jour": tout ce qui suit devrait immanquablement être tronqué
2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7834
Donne+FSVDSL_livebox.Internet.softathome.livebox4
Si on ajoute 0a343434 (en ASCII: caractère de fin de ligne suivi de 444), ça donne+FSVDSL_livebox.Internet.softathome.livebox4
444
Oui, c'est bien sur 2 lignes: le caractère de fin de ligne est ici interprété comme un retour à la ligne.Hi,
Je dis ça je dis rien mais la différence entre 4c et 6c (donc L ou l) est ce qui m'a valu quelques galères lors des Renew suite à la migration.
Grosso-modo faut 4c pour ipv4 et ipv6, dixit LeVieux.
option 77: 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836 (pour ipv4)
option 15: 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836 (pour ipv6)
A+
Hi,
Je dis ça je dis rien mais la différence entre 4c et 6c (donc L ou l) est ce qui m'a valu quelques galères lors des Renew suite à la migration.
Grosso-modo faut 4c pour ipv4 et ipv6, dixit LeVieux.
option 77: 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836 (pour ipv4)
option 15: 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7836 (pour ipv6)
A+
Tiens, c'est rigolo, la Livebox 7 est reconnue.
Les deux options suivantes fonctionnent...Code: [Sélectionner]Option 77 : 0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837
Option 15 : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7837
Bientôt sur le marché ?
J'ai aussi testé avec 8 et 9. Celles-ci ne fonctionnent pas.
@yeoctiBien vu. Merci 👍
Suite à la remarque de @arnaudf, (voir 3 posts plus haut) peut-être faut t'il penser à modifier ton "Option 15" comme suit:
Option 15 : 0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7837
/ip dhcp-client option
add code=60 name=vendor-class-identifier value="'sagem'"
add code=77 name=userclass value="'+FSVDSL_livebox.Internet.softathome.Livebox4'"
/ipv6 dhcp-client option
add code=15 name=userclass value="0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834"
Hello,
Sinon pour le DHCPV4 vous pouvez entrer les chaines comme paramètre:Code: [Sélectionner]/ip dhcp-client option
add code=60 name=vendor-class-identifier value="'sagem'"
add code=77 name=userclass value="'+FSVDSL_livebox.Internet.softathome.Livebox4'"
bien inclure le + sinon cela ne fonctionne pas.
Pour DHCPV6
Cela ne fonctionne pas a cause des 00 devant. j'ai donc comme chaine :Code: [Sélectionner]/ipv6 dhcp-client option
add code=15 name=userclass value="0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834"
Bah, pas besoin justement c'est fait automatiquement, et c'est plus lisible qu'une chaine hexa. ;)
C’est quoi l’intérêt de rebooter tous les jours ?
Ça a un gros impact les bridge filters ? Même si ceux-ci sont limités aux requêtes DHCP liées à Orange ?
Sinon, tu pourrais faire un script pour
- Release DHCP
- Activation des bridges filters
- Génération des nouvelles options 90 et 11
- Request DHCP
- Désactivation des bridge filters
Lancé périodiquement, ça évite le reboot et il pourrait même être associé à un contrôle de perte de connectivité type netwatch.
[ 5] 0.00-1.00 sec 36.2 MBytes 304 Mbits/sec
[ 5] 1.00-2.00 sec 39.6 MBytes 332 Mbits/sec
[ 5] 2.00-3.00 sec 39.7 MBytes 333 Mbits/sec
[ 5] 1.00-2.00 sec 61.7 MBytes 518 Mbits/sec
[ 5] 2.00-3.00 sec 61.7 MBytes 518 Mbits/sec
[ 5] 3.00-4.00 sec 61.7 MBytes 518 Mbits/sec
option dhcp-client-identifier 1:a4:ce:xx:xx:xx:xx;
option Vendor-Specific-Information 0:0:5:58:c:1:a:0:1:0:0:0:0:0:0:0:0; <--------------
renew 2 2023/04/11 15:30:59;
rebind 0 2023/04/16 06:38:27;
expire 1 2023/04/17 16:14:27;interface "eth1.832";
ia-pd da:xx:xx:xx{
starts 1681083538;
renew 84672;
rebind 483840;
iaprefix 2a01:cb10:xxxx:xx00::/56 {
starts 1681083538;
preferred-life 604800;
max-life 604800;
}
option dhcp6.vendor-specific-info 0:0:5:58:0:1:0:c:0:1:0:0:0:0:0:0:0:0; <-----------------
option dhcp6.client-id 0:3:0:1:a4:xx:xx:xx:xx;
option dhcp6.server-id 0:3:0:1:a4:7b:2c:4f:ca:1f;
option dhcp6.domain-search "STR.access.orange-multimedia.net.";
option dhcp6.auth xxxxx
}@MacManNon, par exemple :
"id de sous-réseau" ==> tu parles de préfixe ipv6 ?
:local dhcpIpv4OptIds [/ip/dhcp-client/option/find where code="90"]
:if ( [:len $dhcpIpv4OptIds] = 1 ) do={
:local dhcpIpv4OptValue [/ip/dhcp-client/option get [:pick $dhcpIpv4OptIds 0] value]
:if ( $dhcpIpv4OptValue = "0x00" ) do={
:local newVal ""
:set newVal ( $newVal . "0x" )
:set newVal ( $newVal . [$getOrangeAuthHex] )
/ip/dhcp-client/option set [:pick $dhcpIpv4OptIds 0] value=$newVal
}
}
:local dhcpIpv6OptIds [/ipv6/dhcp-client/option/find where code="11"]
:if ( [:len $dhcpIpv6OptIds] = 1 ) do={
:local dhcpIpv6OptValue [/ipv6/dhcp-client/option get [:pick $dhcpIpv6OptIds 0] value]
:if ( $dhcpIpv6OptValue = "0x00" ) do={
:local newVal ""
:set newVal ( $newVal . "0x" )
:set newVal ( $newVal . [$getOrangeAuthHex] )
/ipv6/dhcp-client/option set [:pick $dhcpIpv6OptIds 0] value=$newVal
}
}
Du coup je pige pas trop comment c'est possible ?
En le testant à la main, je me retrouve avec une valeur différente dans les options dhcpv4 et v6 ?
pourtant le script à la fin semble quand même assez clair :Code: [Sélectionner]:set newVal ( $newVal . [$getOrangeAuthHex] )Du coup je pige pas trop comment c'est possible ?
Surprise de ce matin, plus de connection via mon ER-X
IP en 172.16.X.X, j'avais heureusement vu sur twitter un lien vers ce post il y a quelques jours/semaines
Un petit update de l'auth plus le rajout de l'option 61 (je suis en IPv4 only) et ça roule.
La bonne syntaxe pour l'option 61 dans le fichier config.boot Ubiquity :
client-option "send dhcp-client-identifier 1:XX:XX:XX:XX:XX:XX;"
Où les 6x XX c'est l'adresse MAC de votre livebox (étiquette en dessous sur la mienne)
Un truc par contre, via le tcpdump présent sur le ER-X j'ai l'option 125 dans la réponse du serveur DHCP qui est sous la forme 0.0.5.xxxxxx
Je ne sais pas quoi en faire ni comment la convertir vers un truc qui colle avec les codes d'erreurs partagés
Merci à tous et surtout Au vieux ! =)
interfaces {
ethernet eth0 {
address dhcp
description Internet
duplex auto
mac XX:XX:XX:XX:XX:XX
speed auto
vif 832 {
address dhcp
description eth0.832
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox4";"
client-option "send dhcp-client-identifier 01:xx:xx:xx:xx:xx:xx;"
client-option "send rfc3118-auth 00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx........:xx.xx.xx;"
client-option "request dhcp-lease-time, dhcp-renewal-time, dhcp-rebinding-time, domain-search, 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 {
ipv6-name WANv6_IN
name WAN_IN
}
local {
ipv6-name WANv6_LOCAL
name WAN_LOCAL
}
}
}
}
Est-ce que tu utilises bien le client dhcp modifié pour la COS6 ?Merci pour ta réponse.
Si tu n'a pas fait de mise à jour du routeur depuis, ça devrait le faire.J'ai mis à jour mon routeur, je suis en 2.0.9 hotfix 6
Sinon, utilises-tu bien la chaine longue pour l'option 90 ? A générer ici : https://jsfiddle.net/kgersen/3mnsc6wy/
firewall {
all-ping enable
broadcast-ping disable
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians enable
name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 1 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 3 {
action drop
description "Drop invalid state"
log disable
state {
invalid enable
}
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable
}
interfaces {
ethernet eth0 {
address dhcp
description Internet
duplex auto
speed auto
vif 832 {
address dhcp
description eth0.832
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send client-identifier 01:xx:xx:xx:xx:xx:xx;"
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:00:00: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 vendor-class-identifier code 60 = string;"
global-option "option client-identifier code 61 = string;"
global-option "option user-class code 77 = string;"
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
}
}
}
}
ethernet eth1 {
description "Raspberry Pi 4 8GO"
duplex auto
speed auto
}
ethernet eth2 {
description "Netgear GS108"
duplex auto
speed auto
}
ethernet eth3 {
duplex auto
speed auto
}
ethernet eth4 {
description "Unifi 1"
duplex auto
poe {
output off
}
speed auto
}
loopback lo {
}
switch switch0 {
address 192.168.1.1/24
description "Netgear GS108"
mtu 1500
switch-port {
interface eth1 {
}
interface eth2 {
}
interface eth3 {
}
interface eth4 {
}
vlan-aware disable
}
}
}
port-forward {
auto-firewall enable
hairpin-nat enable
lan-interface eth1
lan-interface switch0
lan-interface eth2
lan-interface eth3
lan-interface eth4
wan-interface eth0.832
}
protocols {
static {
route6 ::/0 {
next-hop fe80::ba0:bab {
interface eth0.832
}
}
}
}
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 LAN {
authoritative enable
subnet 192.168.1.0/24 {
default-router 192.168.1.1
dns-server 8.8.8.8
dns-server 8.8.4.4
lease 86400
start 192.168.1.38 {
stop 192.168.1.243
}
}
}
static-arp disable
use-dnsmasq disable
}
dns {
forwarding {
cache-size 150
listen-on switch0
}
}
gui {
http-port 80
https-port 443
older-ciphers enable
}
nat {
rule 5001 {
description "masquerade for WAN"
outbound-interface eth0.832
type masquerade
}
}
snmp {
community baslywifi {
authorization ro
}
}
ssh {
port 14610
protocol-version v2
}
}
system {
analytics-handler {
send-analytics-report false
}
crash-handler {
send-crash-report false
}
flow-accounting {
disable-memory-table
ingress-capture post-dnat
interface eth0
netflow {
enable-egress {
engine-id 51
}
engine-id 50
mode daemon
server 82.64.0.209 {
port 2055
}
timeout {
expiry-interval 60
flow-generic 60
icmp 60
max-active-life 60
tcp-fin 10
tcp-generic 60
tcp-rst 10
udp 60
}
version 9
}
syslog-facility daemon
}
ntp {
server 0.ubnt.pool.ntp.org {
}
server 1.ubnt.pool.ntp.org {
}
server 2.ubnt.pool.ntp.org {
}
server 3.ubnt.pool.ntp.org {
}
}
offload {
hwnat enable
ipsec enable
}
syslog {
global {
facility all {
level notice
}
}
}
time-zone UTC
}
traffic-control {
optimized-queue {
policy global
}
}
/* Warning: Do not remove the following line. */
/* === vyatta-config-version: "config-management@1:conntrack@1:cron@1:dhcp-relay@1:dhcp-server@4:firewall@5:ipsec@5:nat@3:qos@1:quagga@2:suspend@1:system@5:ubnt-l2tp@1:ubnt-pptp@1:ubnt-udapi-server@1:ubnt-unms@2:ubnt-util@1:vrrp@1:vyatta-netflow@1:webgui@1:webproxy@1:zone-policy@1" === */
/* Release version: v2.0.9-hotfix.6.5574651.221230.1015 */
Fais une capture du WAN voir la tronche de la requête DHCP.Comme ça ?
kk@kk:/config$ show interfaces ethernet eth0 capture
Capturing traffic on eth0 ...
07:41:14.415631 LLDP, length 22
07:41:40.483984 IP 192.168.1.1.59543 > 255.255.255.255.10001: UDP, length 4
07:41:40.484860 IP 192.168.1.1.39329 > 255.255.255.255.10001: UDP, length 4
07:42:11.432208 IP 192.168.1.1.42318 > 255.255.255.255.10001: UDP, length 4
07:42:11.433264 IP 192.168.1.1.42540 > 255.255.255.255.10001: UDP, length 4
07:42:14.391722 LLDP, length 22
07:42:42.584823 IP 192.168.1.1.48486 > 255.255.255.255.10001: UDP, length 4
07:42:42.585744 IP 192.168.1.1.56948 > 255.255.255.255.10001: UDP, length 4
07:43:13.679967 IP 192.168.1.1.42758 > 255.255.255.255.10001: UDP, length 4
07:43:13.680946 IP 192.168.1.1.37092 > 255.255.255.255.10001: UDP, length 4
07:43:14.367627 LLDP, length 22
[xxxxxx] > /tool/sniffer/export
# apr/20/2023 19:01:18 by RouterOS 7.6
# software id = xxxxxx
#
# model = CCR2004-1G-12S+2XS
# serial number = xxxxxxx
/tool sniffer
set file-limit=100000KiB filter-interface=br-wan filter-ip-protocol=udp filter-port=bootps,bootpc,546,547 filter-stream=yes memory-limit=5000KiB memory-scroll=no streaming-enabled=yes streaming-server=192.168.xxx.xxx
Merci pour l'astuce sur RouterOS, je pourrais en avoir besoin ;) (CCR2004 configuré, prêt à mettre en prod mais aucun test pour l'instant, j'attends un WE ou femme & enfants ne seront pas à la maison ;) ).
IP en 169.254 = IP autoassignée par le PC lui-même.
De toute façon il sera impossible d'obtenir une IP avec le client DHCP de windows puisqu'on ne peut pas paramétrer les options nécessaires. Vu qu'il ne semble y avoir aucune communication DHCP dans la capture, je vais poser une question toute bête: Est-ce que le client patch utilisé est bien pour l'architecture CPU de l'ER-X ? les ERL/ER4 et ER-X n'utilisent pas la même architecture CPU et donc les binaires ne sont pas interchangeables...
Que donne l'exécution manuelle de dhclient3 sans paramètres ?
Et ça fonctionne ... mieux. J'ai une ip : 172.16.......Parqué, donc oui, un problème d'options.
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
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
Option: (61) Client identifier
Option: (77) User Class Information
Option: (90) Authentication
Option: (255) Endinterfaces {
ethernet eth0 {
address dhcp
description Internet
duplex auto
mac adresseMacLivebox
speed auto
vif 832 {
address dhcp
description eth0.832
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send dhcp-client-identifier 01:adresseMacLivebox;"
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:chaînelongue.....;"
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;"
default-route update
default-route-distance 210
global-option "option vendor-class-identifier code 60 = string;"
global-option "option client-identifier code 61 = string;"
global-option "option user-class code 77 = string;"
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
}
}
} ethernet eth0 {
address dhcp
description Internet
duplex auto
mac mac livebox
speed auto
vif 832 {
address dhcp
description eth0.832
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send dhcp-client-identifier 01:mac livebox;"
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:00:00:chaîne longue"
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;"
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
}
}
}
}Moi sur l'USG Pro je rentrais la MAC avec les deux points...Merci :)
ethernet eth1 {
description "eth1 - ONT"
duplex auto
speed auto
vif 832 {
address dhcp
description "eth1.832 - Internet + VoIP"
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox4";"
client-option "send dhcp-client-identifier 01:A4: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-authentication, domain-search, SIP-servers, Vendor-Specific-Information;"
client-option "send rfc3118-authentication 00:00:00:00:00:00:00:00:00:00:00:....chaine longue...;"
default-route update
default-route-distance 210
global-option "option rfc3118-authentication code 90 = string;"
global-option "option SIP-servers code 120 = string;"
global-option "option Vendor-Specific-Information code 125 = string;"
name-server no-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
}
mac xx:xx:xx:xx:xx:xx
}
vif 840 {
address 192.168.40.1/24
description "eth1.840 - TV"
egress-qos "0:5 1:5 2:5 3:5 4:5 5:5 6:5 7:5"
}
}
interfaces {
ethernet eth0 {
address dhcp
description Internet
duplex auto
speed auto
mac XX:XX:XX:XX:XX:XX
speed auto
vif 832 {
address dhcp
description eth0.832
dhcp-options {
client-option "send vendor-class-identifier "sagem";"
client-option "send user-class "\053FSVDSL_livebox.Internet.softathome.Livebox4";"
client-option "send dhcp-client-identifier 1: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-authentication, domain-search, SIP-servers, Vendor-Specific-Information;"
client-option "send rfc3118-authentication 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:XX:XX:XX:XX:XX:XX:XX:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx;"
default-route update
default-route-distance 210
global-option "option rfc3118-authentication code 90 = string;"
global-option "option SIP-servers code 120 = string;"
global-option "option Vendor-Specific-Information code 125 = string;"
name-server no-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
}
}
}
}root@ER-6P:/var/run# cat dhclient_eth1_832.leases
lease {
interface "eth1.832";
fixed-address 90.126.xx.xx;
option subnet-mask 255.255.252.0;
option dhcp-lease-time 604800;
option routers 90.126.xx.1;
option dhcp-message-type 5;
option dhcp-server-identifier 80.10.238.81;
option domain-name-servers 81.253.149.13,80.10.246.5;
option domain-search "STR.access.orange-multimedia.net.";
option dhcp-renewal-time 81169;
option broadcast-address 90.126.xx.255;
option rfc3118-authentication 0:0:0:0:0:0:0:0:0:0:0:xxxxxxxxxxxxxxxx;
option dhcp-rebinding-time 483840;
option host-name "ER-6P";
option dhcp-client-identifier 1:a4:xx:xx:xx:xx:xx;
option Vendor-Specific-Information 0:0:5:58:c:1:a:0:1:0:0:0:0:0:0:0:0;
renew 3 2023/04/26 02:51:35;
rebind 0 2023/04/30 22:10:48;
expire 2 2023/05/02 07:46:48;
}
Les messages retour sont beaucou plus riches, mais je suis toujours parqué.
Mauvaise auth ? Option ? ONT ?
Le seul souci que je vois : je passe peut-être trop rapidement d'un routeur à l'autre, il faudrait peut-être attendre un certain temps (comme le fut du canon)
DUID et MAC : Principe général : éviter de jouer avec pour en changer trop vite ... On a des fonctions dans le réseau qui limitent le nbe de DUID / MAC derrière un même accès. Mais cela vous le saviez déjà.
Avec une temporisation de clear "d 'un certain temps" ..
Eteindre ou débrancher l'ONT, je ne suis pas certain que cela nettoie à 100% de chance ton contexte dans le OLT/DSLAM face à ta ligne, je vais vérifier ce point, mais je ne pense pas.
Je cite @LeVieuxAtOrange, changer de router (avec le changement de MAC) pose problème :
lease {
interface "eth0.832";
fixed-address 172.16.XX.XX;
option subnet-mask 255.255.0.0;
option routers 172.16.0.1;
option dhcp-lease-time 3720;
option dhcp-message-type 5;
option domain-name-servers 80.10.246.1,81.253.149.9;
option dhcp-server-identifier 80.10.233.113;
option domain-search "CAE.access.orange-multimedia.net.";
option dhcp-renewal-time 2976;
option dhcp-rebinding-time 2976;
option rfc3118-auth 0:0:0:0:0:0:0:0:0:0:0:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX;
option broadcast-address 172.16.255.255;
option host-name "kk.erx";
option dhcp-client-identifier 1:5c:XX:XX:XX:XX:XX;
option Vendor-Specific-Information 0:0:5:58:c:1:a:0:1:1:2:1:0:0:0:0:0;
renew 2 2023/04/25 20:27:12;
rebind 2 2023/04/25 20:32:27;
expire 2 2023/04/25 20:44:51;Frame 2: 443 bytes on wire (3544 bits), 443 bytes captured (3544 bits)
Ethernet II, Src: Alcatel-_c5:7e:d7 (0c:a4:02:c5:7e:d7), Dst: Sagemcom_61:9f:f0 (5c:fa:25:61:9f:f0)
802.1Q Virtual LAN, PRI: 7, DEI: 0, ID: 832
Internet Protocol Version 4, Src: 80.10.233.113, Dst: 172.16.207.58
User Datagram Protocol, Src Port: 67, Dst Port: 68
Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xaa32b22f
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 172.16.XXX.XX
Next server IP address: 80.10.233.113
Relay agent IP address: 80.10.233.113
Client MAC address: Sagemcom_61:9f:f0 (5c:XX:XX:XX:XX:XX)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier (80.10.233.113)
Option: (51) IP Address Lease Time
Option: (1) Subnet Mask (255.255.0.0)
Option: (3) Router
Option: (6) Domain Name Server
Option: (28) Broadcast Address (172.16.255.255)
Option: (12) Host Name
Option: (61) Client identifier
Option: (90) Authentication
Option: (125) V-I Vendor-specific Information
Length: 17
Enterprise: Orange (1368)
Length: 12
Option 125 Suboption: 1
Length: 10
Data: 00010102010000000000
Option: (119) Domain Search
Option: (58) Renewal Time Value
Option: (59) Rebinding Time Value
Option: (255) EndC'est le Data: 00010102010000000000 qu'il faut regarder ? Si oui, c'est bien un mauvais user/psswd qui est mentionné ?Le canal retour :
Dans la réponse DHCP il y a un canal de retour du réseau.
C'est l'option 125 en DHCPv4, l'option 17 en DHCPv6
Le contenu (attention, les entêtes des options sont différentes, voir les RFC) est le même et dans le format suivant avec en rouge 2 octets de code d'information : 0001000000ffffffffff
Les grandes classes de réponses sont :
- 00xx : OK vu du réseau Orange et tout doit fonctionner. Si ce n'est pas le cas le problème vient de chez vous.
- 01xx : Le modèle de box, le firmware ou votre ligne est bloquée (0102 ce qui peut arriver si le comportement de votre routeur est trop agressif ...) 0199 en cas de mauvaise COS sur le DHCP
- 02xx : erreur de Login ou de Mot de passe ou d'encodage
- 03xx : compte ou service probablement résilié
- 04xx : problème de règlement de la facture avec de possibles limitation de débit ou blocage.
Bonjour,
J'ai terminé ce matin la config IPv6 de mon ERL.
Premier démarrage : tout est fonctionnel, IPv4 et IPv6.
Je n'ai fait aucune modif sur la conf IPv4. Je récupère la même IPv4 et même préfixe /56 IPv6.
Je ne vois pas pourquoi la partie IPv4 est devenue fonctionnelle ??? mystère et boule de gomme ... j'ai dû louper un truc ...
Je me pose plusieurs questions sur mon problème.
La partie Authentication ne répond aucun problème dans le discover (contrairement à ce qu'indique Renaud07, rien en jaune). Par contre dans le Offer j'ai bien data suivant : 00010102010000000000
Si la partie en rouge est bien la bonne à regarder, dans le bon paquet, mauvais user/psswd ou format, comment puis-je régler le problème ? J'ai vérifié le user, le mot de passe (renvoyé par Orange hier soir), utilisé le générateur en page 1....
Je compare les paquets capturés avec ce qu'on doit avoir en IPV4 selon levieux, tout est identique sauf que je transmet l'option 12 (Host name), nom perso. Je ne crois pas être le seul, mais comment faire pour ne pas la transmettre ? Si je la supprime de mon fichier de config, il met par défaut ubnt et c'est quand même transmis ... Est-ce un problème de transmettre l'option 12 ?
Quand je regarde mon fichier leases, vois que les renew/rebind/expire sont dans le passé (de 1 à 2 jours). Mon routeur n'est plus à la bonne date. Est-ce un problème ? J'essaie de la changer, mais sans serveur NTP ça saute...
Bonjour,
pour récupérer la bonne valeur on peut utiliser le logiciel liveboxinfo. ça peut permettre de debug.
sinon, il y a la solution de mettre le wan de la box sur un port ethernet du pc, pour voir ce qu'elle envoie avec une capture wireshark
[admin@MikroTik] > /ip dhcp-client option add code=60 name=vendor-class value=0x736167656d
[admin@MikroTik] > /ip dhcp-client option add code=61 name=clientid value=0x0144A6zzzzzzzz (basé sur la mac de la lb4)
[admin@MikroTik] > /ip dhcp-client option add code=77 name=user-class value=0x2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
[admin@MikroTik] > /ip dhcp-client option add code=90 name=authentication value=0x+140 caractères (généré par le script de @kgersen).
[admin@MikroTik] > /ipv6 dhcp-client option add code=1 name=clientid value=0x0003000144A6zzzzzzzz (basé sur la mac de la lb4)
[admin@MikroTik] > /ipv6 dhcp-client option add code=11 name=authentication value=0x+140 caractères (généré par le script de @kgersen).
[admin@MikroTik] > /ipv6 dhcp-client option add code=15 name=user-class value=0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7834
[admin@MikroTik] > /ipv6 dhcp-client option add code=16 name=vendor-class value=0x0000040e0005736167656d
[admin@MikroTik] > /ipv6 dhcp-client option add code=17 name=vendor-infos value=0x000005580006000e495056365f524551554553544544
Je n'ai pas été trop clair sur l'option 61, désolé.
Sur le Mikrotik, par défaut pour le client DHCP on a déjà 2 options 61 paramétrées :
clientid_duid : 0xff$(CLIENT_DUID)
clientid : 0x01$(CLIENT_MAC)
Actuellement j'utilise la valeur 0xff$(CLIENT_DUID). Il me semble que c'est également basée sur la Mac mais là je ne suis pas chez moi je ne peux pas vérifier, mais j'avoue ne pas trop saisir la différence entre les 2 valeurs possibles!
On trouve ça dans leur doc :
CLIENT_MAC - client interface MAC address;
CLIENT_DUID - client DIUD of the router, same as used for the DHCPv6 client. In conformance with rfc4361
Du coup j'ai mis DUID pour avoir une cohérence ipv4/v6, chez vous c'est comment ?
3 * clientid_duid 61 0xff$(CLIENT_DUID) ff
4 * clientid 61 0x0144A61Exxxxxx 0144a61exxxxxx (xxxxxx fin de la mac adress de la lb4)
Est-ce que tu as moyen de faire une capture de la transaction DHCPv6 ? Afin que le code de status confirme que 1. c'est migré 2. les options sont ok
J'ai vu des gens rapporter un code différent entre Advertise et Reply aussi, est-ce qu'on a une réponse définitive sur ce à quoi il faut se fier ?
Je parlais d'une capture de l'interface WAN de ton routeur seul, qui semble marcher en v6.
Ai-je mal compris la situation ?
Et donc en v6 l'option 17 te dit 0000 ?
Parceque ce n'est pas censé être possible car si un proto est en défaut et que l'autre devrait fonctionner, cela implique une configuration incohérente donc parcage.
à priori ma box fallback en PPPoE sur le vlan 835 (c'est une livebox3), ca doit être sa façon à elle de gérer le problème de dhcp....
c'est peut être tout simplement qu'elle n'est pas à jour une fois à jour, je pense qu'elle reprendra la conf par le vlan 832 dhcp
Je constate que l'ONU à un Tx à -40dBm depuis 5h48 (au lieu de 2.5dBm habituellement). Le Rx est correct -17dBm.
Je fais powerOff/powerOn sur le CRS305, le signal est de nouveau ok, les clients dhcp (ipv4 et ipv6).
J'ai l'impression que depuis l'installation de ROS 7.8 sur mon CRS305, j'ai le Tx qui chute brutalement. Le problème se résout en faisant powerOff/PowerOn du CRS305.
Ce problème arrive assez rarement (1 fois tous les 2/3 mois ?). Je n'ai pas l'impression d'avoir eu ce phénomène en ROS 7.7 et 7.6.
Cela peut-il venir de l'infra Orange ? Je ne pense pas car c'est le Tx de l'ONU qui tombe. Si c'était l'infra Orange, j'aurais un pb de Rx, enfin je crois...
Une idée ?
Merci.
PS: j'ai posté aussi sur le sujet Mikrotik car c'est peut-être spécifique...
Le bail est de 7j d'après le mikrotik.3j c'était avant la migration. depuis la migration, (réalisée hier pour ma part), c'est 7j
Il me semble avoir lu que ça passait à 3j non ?
Bonjour,
Je tourne avec une config ipv4/ipv6 et systemd-networkd, le 05/04 le client DHCPv4 a cessé de renouveller correctement les baux.
Je fais tourner un cron toutes les 19h pour restart les clients DHCPv4,6 et ainsi relancer les cycles et redevenir routable sur wan 832.
Quelqu'un a remarqué ce comportement ? Peut-être spécifique à systemd...
Cheers,
johnk
Bonjour
Petit rappel à tous, le contrôle des paramètres User Class est CASE SENSITIVE
Donc pour tous, mettre
FSVDSL_livebox.Internet.softathome.Livebox6
comme UserClass
En respectant BIEN les majuscule / minuscule
Il n'y a pas de contrôle entre votre fti et votre firmware ...
LeVieux
Je suppose que ton renew n'est pas tagué en COS6 ?
Thank you for responding. I know those settings are advised, but my pfSense with a fs.com ONT SFP worked like a charm for 2 years until this winter when Orange tightned the DHCP protocol compliance. Now I get an IP just fine and it works for about 24 hours until the DHCP renew. Then the line stops responding and I have to login and do a DHCP release and renew to get it going again. I suspect perhaps the Renew is not COS6 tagges out of pfSense as the discover frame is when configured on the DHCP client.
...
Identity Association for Prefix Delegation
Option: Identity Association for Prefix Delegation (25)
Length: 48
IAID: 00000014
T1: 0
T2: 0
Status code
Option: Status code (13)
Length: 32
Status Code: NoPrefixAvail (6)
Status Message: No prefixes have been assigned
Authentication
Option: Authentication (11)
Length: 27
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 646863706c697665626f786672323530
Vendor-specific Information
Option: Vendor-specific Information (17)
Length: 18
Enterprise ID: Orange (1368)
option
Option code: 1
Option length: 12
Option data: 000100000000000000000018
I suspect perhaps the Renew is not COS6 tagges out of pfSense as the discover frame is when configured on the DHCP client.Most likely this is the issue. Users of OPNSense faced the same problem and correctly tagging renew request with CoS 6 fixed it...
Most likely this is the issue. Users of OPNSense faced the same problem and correctly tagging renew request with CoS 6 fixed it...Okay - that does seem to indicate this might be my problem. I will stage a full packet capture tonight when the renew attempt happens again, and then I’ll know if the Renew is COS6 tagged or not.
Hello,As-tu pensé à désactiver le Rapid Commit ?
Je suis en cours de déploiement de mon CCR2004 à la place de l'ER4. Pas de problème en IPv4, mais en IPv6, baobab me répond ça:
...
En même temps ton Mikrotik devrait te laisser le choix, il y a un topic pour les Mikrotik.On ne peut pas changer l'IAID sur Mikrotik, il est dérivé de l'index de l'interface...
Bonjour,
Je tourne avec une config ipv4/ipv6 et systemd-networkd, le 05/04 le client DHCPv4 a cessé de renouveller correctement les baux.
Je fais tourner un cron toutes les 19h pour restart les clients DHCPv4,6 et ainsi relancer les cycles et redevenir routable sur wan 832.
Quelqu'un a remarqué ce comportement ? Peut-être spécifique à systemd...
Cheers,
johnk
Thank you for responding. I know those settings are advised, but my pfSense with a fs.com ONT SFP worked like a charm for 2 years until this winter when Orange tightned the DHCP protocol compliance. Now I get an IP just fine and it works for about 24 hours until the DHCP renew. Then the line stops responding and I have to login and do a DHCP release and renew to get it going again. I suspect perhaps the Renew is not COS6 tagges out of pfSense as the discover frame is when configured on the DHCP client.
The lease comes with a renew interval of aprox. 24 hours, a rebind interval of about 6 days, and an expiration interval of 7 days.
It’s normal for a DHCP client to attempt renew when the renew timer (T1) expires, so pfSense is just doing what it’s suppose to.
But as soon as a renew reqeust has been sent, the line stops routing traffic, so Orange must consider something wrong with that attempt, and shut down routing.
I then have to do a full DHCP release and renew to get another ~24 hours.
It’s a single stack IPv4 only setup.
Okay - that does seem to indicate this might be my problem. I will stage a full packet capture tonight when the renew attempt happens again, and then I’ll know if the Renew is COS6 tagged or not.
I believe i can create a floating match rule in pfSense that looks for - and priority tags - DHCP frames going out of my WAN VLAN interface.
That way there is no need to have the DHCPv4 client modified to tag renews if it does not support this right now. I know it correctly tags discover frames currently.
# DHCPv6
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p udp --sport dhcpv6-client --dport dhcpv6-server -j CLASSIFY --set-class 0:6
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p udp --sport dhcpv6-client --dport dhcpv6-server -j DSCP --set-dscp-class CS6
# NDP RS (133/0)
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p icmpv6 --icmpv6-type router-solicitation -j CLASSIFY --set-class 0:6
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p icmpv6 --icmpv6-type router-solicitation -j DSCP --set-dscp-class CS6
# NDP NS (135/0)
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p icmpv6 --icmpv6-type neighbour-solicitation -j CLASSIFY --set-class 0:6
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p icmpv6 --icmpv6-type neighbour-solicitation -j DSCP --set-dscp-class CS6
# NDP NA (136/0)
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p icmpv6 --icmpv6-type neighbour-advertisement -j CLASSIFY --set-class 0:6
ip6tables -t mangle -I POSTROUTING -o $INTERFACE -p icmpv6 --icmpv6-type neighbour-advertisement -j DSCP --set-dscp-class CS6
(règles ip6tables pour ajouter la prio sur DHCPv6 et NDP)Je suis en train de mettre mes outils à jour pour le futur (pas encore migré) et j'essaye de release le bail DHCPv6 correctement. L'objectif est de peut-être implémenter une surveillance du lien montant, ou au mois de pouvoir reset proprement à la main en une commande.J'en profite pour up ma question, même si après pas loin de 80 pages et quelques mois j'ai peu d'espoir d'avoir une réponse.
Mon dhclient s'amuse à envoyer toutes les options dans le message Release, ce qui déplait au serveur qui logiquement n'en a pas besoin : je reçois une réponse Reply avec un Status code (option 13) UnspecFail (code 1). C'est cohérent d'après ce que dit la RFC : le serveur peut répondre UnspecFail si on lui demande des options inattendues.
Est-ce un problème ? (ça vous fait du bruit inutile ?) En l'état est-ce que le bail est bien relâché ?
Oyez Oyez braves experts ou moins experts à la recherche de la lumière de LaFibreMerci pour le support que tu as apporté sur ce sujet :)
La migration est presque achevée, il reste moins de 4% des clients DHCP non migrés sur des "queues de comètes".
Les derniers devraient avoir migrés dans les 15 jours.
Fin de cette magnifique phase du projet avec une migration de plus de 10 millions de clients sans gros soucis (plein de petites "merdouilles" mais cela c'est la vie normal d'un tel mouvement d'ampleur ...)
LeVieux (pour vous servir)
Oyez Oyez braves experts ou moins experts à la recherche de la lumière de LaFibre
La migration est presque achevée, il reste moins de 4% des clients DHCP non migrés sur des "queues de comètes".
Les derniers devraient avoir migrés dans les 15 jours.
Fin de cette magnifique phase du projet avec une migration de plus de 10 millions de clients sans gros soucis (plein de petites "merdouilles" mais cela c'est la vie normal d'un tel mouvement d'ampleur ...)
LeVieux (pour vous servir)
Oyez Oyez braves experts ou moins experts à la recherche de la lumière de LaFibre
La migration est presque achevée, il reste moins de 4% des clients DHCP non migrés sur des "queues de comètes".
Les derniers devraient avoir migrés dans les 15 jours.
Fin de cette magnifique phase du projet avec une migration de plus de 10 millions de clients sans gros soucis (plein de petites "merdouilles" mais cela c'est la vie normal d'un tel mouvement d'ampleur ...)
LeVieux (pour vous servir)
Question bonus : Sais-tu si un autre truc du genre nous attend ? Un truc qui nous obligerait à revoir nos configurations.Re
De ce que je comprends, il n'est à priori pas possible de modifier la configuration de l'Orbi pour le remettre en configuration routeur sans livebox. Ce qui je lis sur le thread, montre pas mal de configuration pour un routeur de type "opensource" Ai-je le bon point de vue ou j'ai loupé quelque chose ?C’est ça. Peu probable que Netgear fasse l’effort de mettre à jour le firmware.
[...]ahh... CGN, ahhh partage d'IPv4. mais bon c'est inéluctable. tant qu'on a le choix entre du CGN et un morceau d'ipv4 publique. comme tu le dis, c'est aussi une façon de pousser l'ipv6 pour tout, enfin tout ce qui le supporte.
Je dirais quelques années.
Prochain gros morceaux sur la trajectoire cela va être le passage en CGN et partage d'IPv4.
Je sais pas encore comment cela va se dérouler ni quand.
[...]
LeVieux
Perso j'ai essayé "pour voir" comment c'est Internet sans IPv4... À part Google, Wikipedia, Amazon et notre bien aimé temple Lafibre.info, y'a pas grand chose qui marche. 😥
faire un cycle DHCP (release et recommencer à 0) fait revenir la connexion. Y'a plus qu'à scripter...Fait. Maintenant j'attend que ça casse, pour tester...
"Désolé M. l'inspecteur des impôts, j'ai pas pu remplir ma déclaration, votre site est seulement accessible en IPv4 !"(https://lafibre.info/images/smileys/Confus_27.gif)
Perso j'ai essayé "pour voir" comment c'est Internet sans IPv4... À part Google, Wikipedia, Amazon et notre bien aimé temple Lafibre.info, y'a pas grand chose qui marche. 😥Hello
DHCP VLAN Priority: 6 et le Option modifiers: vlan-pcp 6noipv4ll
nohook hostname resolv.conf timesyncd.conf
allowinterfaces eno1.832
debug
logfile /var/log/dhcpcd.log
noauthrequired
noarp
noipv6rs
interface eno1.832
iaid xxxxxxxx
ia_pd xxxxxxxx br0//64
ipv6rs
clientid
userclass FSVDSL_livebox.Internet.softathome.Livebox4
vendclass 1038 sagem
vendorclassid sagem
broadcast
option subnet_mask routers domain_name_servers domain_name broadcast_address dhcp_lease_time dhcp_renewal_time dhcp_rebinding_time domain_search sip_server 125 auth
option dhcp6_vivso dhcp6_name_servers dhcp6_domain_search dhcp6_auth
nooption 33 57
authprotocol token 0x123/0x456
authtoken 0x456 "" forever 64:68:63:70:6c:69:76:65:62:6f:78:66:72:32:35:30
authtoken 0x123 "" forever 1a:09:00:00:05:58:01:03:41:01:0d:66:74:69:2f:...
J'utilise la même depuis au moins 3 ans.Bonjour
LeVieux disait il y a un bout de temps déjà, et réaffirme ici, qu'Orange ne fait pas d'anti-rejeu et n'a pas l'utilité de le faire. Donc pas besoin de les régénérer automatiquement.OK - simplement ça n'était pas si évident à comprendre lorsqu'on lit qu'il y a des "proto B et C" en stock
OK - simplement ça n'était pas si évident à comprendre lorsqu'on lit qu'il y a des "proto B et C" en stockHello
| Fabricant | Vendor DHCP | Code IANA (préfixe de l'option 16) | ||
| Sagemcom | "sagem" | 1038 (SAGEMCOM SAS) | ||
| Sercomm | "sercomm" (?) | 915 (SerComm Corp.) | ||
| Arcadyan | "arcadyan" (?) | 32981 (Arcadyan Technology Corporation) |
Bonjour, j'ai eu à nouveau le même problème aujourd'hui : déconnexion soudaine, requête DHCP invalide, j'ai recopié la valeur de l'option 90 de la Livebox, je l'ai mise sur mon client DHCP sur mon routeur Mikrotik, et l'internet est de retour.
au risque d'avoir raté une discussion sur le sujet, quand on parle du protocole A/B/C, c'est lié au Byte de l'option 90 que l'on laisse par défaut à A aujourd'hui?Bonjour
S'il y a de la doc sur ce sujet pour la culture générale, je suis intéressé.
Bonjour, j'ai eu à nouveau le même problème aujourd'hui : déconnexion soudaine, requête DHCP invalide, j'ai recopié la valeur de l'option 90 de la Livebox, je l'ai mise sur mon client DHCP sur mon routeur Mikrotik, et l'internet est de retour.Bonjour
Bonjour,
Quelles sont les valeurs possibles pour le fabriquant (Vendor Class, option 16 du DHCP V6) dans l'univers des potentielles box Orange concernées par l'IP V6 ?
En fouillant un peu dans le forum pour trouver les codes IANA, j'ai pu en trouver 2 potentielles en plus de la string 'sagem', mais pour les versions Pro je ne sais pas trop
Fabricant Vendor DHCP Code IANA (préfixe de l'option 16) Sagemcom "sagem" 1038 (SAGEMCOM SAS) Sercomm "sercomm" (?) 915 (SerComm Corp.) Arcadyan "arcadyan" (?) 32981 (Arcadyan Technology Corporation)
y a-t-il des possesseurs de Livebox qui ne sont pas fabriquées par SagemCom (donc qui le sont par Sercomm ou Arcadyan ou autres) ?Un ami qui c'est fait rempalcer sa livebox 3 a hérité d'une livebox 5 Arcadyan, celle ci met entre 5 et 10 minutes a démarer (internet accessible en ethernet) contrairement a une sagem (que je posséde) qui rend internet disponible en 3 a 5 minutes
Un ami qui c'est fait rempalcer sa livebox 3 a hérité d'une livebox 5 ArcadyanA sa demande ? (l'échange est facturé 10€ il me semble)
A sa demande ? (l'échange est facturé 10€ il me semble)A sa demande oui, je ne me souvient pas si orange lui avait facturé le changement, je ne crois pas
ça me parait énorme même 3 à 5 voire 10 minutes pour avoir internet.A partir du moment ou la livebox affiche des signes de vie (led internet globe qui cligniote), je mets au moins une a 2 minutes avant d'avoir la led suivante (wifi) qui cligniote, et entre 3 a 5 minutes pour avoir les 3 leds fixe, cela dit, il n'est pas impossble que mon exemplaire soit defectueux, en attandant elle fonctionne, sachant que on la redémare rarement, ce n'est pas vraiement un probléme
vous comptez 3 à 5 minutes à partir de quoi ?
Mes parents ont toujours une Livebox 3.
Pour rappel, le FAI nous avait déjà confirmé que la Livebox blanche était également compatible avec l'IPv6.Je n'ai pas eu de livebox 2 après 2015. Je pourrais peut être vérifier ça sur une livebox 2 ADSL début Aout.
Option Request
Option: Option Request (6)
Length: 8
Value: 000b001100170018
Requested Option code: Authentication (11)
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
The Option Request option MUST NOT include the following options: :
(...)
- Authentication (see Section 21.11)
(...)
Tu peux ou pas avoir l'option 11 dans ORO, ca n'a pas d'incidence. Ce qui compte, c'est que tu aies l'option 11 dans tes requêtes (vs avoir l'option 11 dans ORO).
Concrètement : Si j'enlève 11 de l'ORO, ça marchera ? (donc je ne garde que 17,23,24)
ça je le sais bien...je connais par coeur les options des requêtes DHCPv6...
https://github.com/fgero/dhcpv6-mod
Non, non, je développe (et utilise depuis 1 mois sans souci) un mod pour les Dream Machines Unifi, en open source sous Github, qui permet d'obtenir un bail DHCP v6 en plus du v4, ce qui est impossible de base
Et comme ça marche bien, je l'étends en donnant la possibilité de générer les options pour tout autre ISP qu'Orange, ou tout évol des requirements Orange
Je te remercie en tout cas pour ta réponse, je vais mettre un défaut à 17,23,24
Bonjour !Bonjour
Est-ce que cela serait compatible avec mon projet ?
https://lafibre.info/gpon/ont-xgs-pon-compatible/new/#new
Bonjour
Je ne suis pas certain se saisir la question : DHCP c’est dans les couches réseau supérieures donc indépendant du mode de connexion fibre - mais j’ai du louper quelque chose :-[
Le choix de l'ONT n'a aucun rapport avec la configuration DHCP d'un routeur.
Accessoirement, pour l'instant il n'y a pas de XGS-PON chez Orange. Impossible donc de savoir si l'ONT XGS-PON de FS.COM sera compatible avec les OLT XGS-PON d'Orange avant que des offres ne soient commercialisées.
Le seul cas que m'évoque un rejet de requête DHCP (au beau milieu d'une connexion qui marchait) est le renew à mi-bail envoyé sans la CoS 6 (on a du patcher le renew d'Unifi, qui ne le faisait pas...)
Bonjour
Faire juste en test en rebootant le routeur.
Si cela passe c'est probablement une erreur de QoS sur le renew.
Erreur de QoS qui se traduit dans le réseau par une requête qui monte sans identifiant de ligne (pour les équipements qui laissent passer cela, c'est pas le cas de tous) et dans cas cas le comportement c'est BLAST.
LeVieux
sudo systemctl restart dhclient6Faut que je regarde la doc de dhclient6 voir si il y a moyen de le forcer à faire un cycle complet ...PS: ton message précédent est la millième réponse dans cette discussion :oAh oui, j'avais pas fait gaffe ;D
iperf3 -c paris.testdebit.info -p 9200-9240 -b 500m -i 2 -t 20
Connecting to host paris.testdebit.info, port 9200
[ 5] local 192.168.0.64 port 46998 connected to 89.84.1.194 port 9200
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-2.00 sec 53.0 MBytes 222 Mbits/sec 415 618 KBytes
[ 5] 2.00-4.00 sec 49.2 MBytes 207 Mbits/sec 1 724 KBytes
[ 5] 4.00-6.00 sec 48.0 MBytes 201 Mbits/sec 0 814 KBytes
[ 5] 6.00-8.00 sec 51.4 MBytes 215 Mbits/sec 5 547 KBytes
[ 5] 8.00-10.00 sec 50.5 MBytes 212 Mbits/sec 0 667 KBytes
[ 5] 10.00-12.00 sec 47.0 MBytes 197 Mbits/sec 0 762 KBytes
[ 5] 12.00-14.00 sec 48.8 MBytes 204 Mbits/sec 3 471 KBytes
[ 5] 14.00-16.00 sec 48.6 MBytes 204 Mbits/sec 0 602 KBytes
[ 5] 16.00-18.00 sec 49.4 MBytes 207 Mbits/sec 0 711 KBytes
[ 5] 18.00-20.00 sec 51.6 MBytes 217 Mbits/sec 0 505 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.00 sec 497 MBytes 209 Mbits/sec 424 sender
[ 5] 0.00-20.05 sec 495 MBytes 207 Mbits/sec receiver
iperf Done.
iperf3 -c paris.testdebit.info -p 9200-9240 -b 500m -i 2 -t 20 -R
Connecting to host paris.testdebit.info, port 9200
Reverse mode, remote host paris.testdebit.info is sending
[ 5] local 192.168.0.64 port 49990 connected to 89.84.1.194 port 9200
[ ID] Interval Transfer Bitrate
[ 5] 0.00-2.00 sec 17.9 MBytes 74.9 Mbits/sec
[ 5] 2.00-4.00 sec 17.9 MBytes 75.1 Mbits/sec
[ 5] 4.00-6.00 sec 17.7 MBytes 74.3 Mbits/sec
[ 5] 6.00-8.00 sec 17.8 MBytes 74.9 Mbits/sec
[ 5] 8.00-10.00 sec 17.8 MBytes 74.5 Mbits/sec
[ 5] 10.00-12.00 sec 17.7 MBytes 74.2 Mbits/sec
[ 5] 12.00-14.00 sec 17.7 MBytes 74.1 Mbits/sec
[ 5] 14.00-16.00 sec 17.7 MBytes 74.2 Mbits/sec
[ 5] 16.00-18.00 sec 17.8 MBytes 74.5 Mbits/sec
[ 5] 18.00-20.00 sec 16.2 MBytes 67.8 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-20.04 sec 177 MBytes 74.2 Mbits/sec 0 sender
[ 5] 0.00-20.00 sec 176 MBytes 73.9 Mbits/sec receiver
Bonjour,
je suis nouveau ici je vous prie d'avoir un peu de patience.
J'ai un abonnement Orange Fibre avec une Livebox 3 et la box fibre, mais je souhaiterait changer de routeur (la livebox c'est bien, mais le logiciel est obsolète et ils manquent beaucoup de fonctionnalités).
Si j'achète un Nighthawk XR500 sous DumaOS, est-ce que je vais pouvoir me connecter simplement à la fibre ?
Est-ce qu'il y a des paramètres à prendre en considération ?
Est-ce que je vais pouvoir avoir de l'ipv4 et de l'ipv6 ?
Merci par avance
Hello Gnubyte,
Merci pour ton retour, je cherche justement un AP qui pourrait tenir la route.
Saurais-tu par hasard si le NWA50AX Pro ?
- Fait le lan en 2,5Gbit
- Est alimentable en PoE
- Peut faire plusieurs ssid 2,4G ou 5G (probablement), chacun sur un vlan
A+
EDIT : je m'auto-réponds, celui-là à l'air de cocher toutes les cases ==> https://www.fs.com/fr/products/149656.html (mais le double du prix)
J'imagine que ce sera une migration par vague mais sera-t-elle forcée ?Pourquoi forcée ? GPON et XGS-PON ne fonctionnent pas sur les mêmes longeurs d'ondes et peuvent donc cohabiter dans une même fibre.
Pourquoi forcée ? GPON et XGS-PON ne fonctionnent pas sur les mêmes longeurs d'ondes et peuvent donc cohabiter dans une même fibre.Je confirme :
reste à trouver un SFP+ XGS-PON compatible, et c'est pas gagné (il y en a un chez fs.com, mais à priori totalement fermé et à plus de 200 euros).J'en vois deux chez FS, avec une différence sur la longueur d'onde RX:
J'en vois deux chez FS, avec une différence sur la longueur d'onde RX:Le premier (malgré son nom) n'est qu'une optique avec des longueurs d'ondes compatibles XGS-PON. Pour fonctionner il doit être inséré dans un ONU, installation similaire à Free en 10G-EPON pour ses offres Revolution et Mini4K avec leur gros boitier noir additionnel.
https://www.fs.com/fr/products/141199.html
https://www.fs.com/fr/products/185594.html
Peut-être qu'Orange proposera de fournir un ONT compatible XGS-PONC'est pas prévu. D'après ce que j'ai compris, avec l'offre Livebox Max Fibre, si on demande un ONT externe, on se retrouve en GPON limité à 1 Gbps au lieu d'être en XGS-PON.
mais après tout, ceux qui ont un ONT Huawei aujourd'hui pour de bonnes raisons (local technique hors portée wifi), comment vont-ils faire ?3 Répéteurs Wifi inclus dans le prix....
C'est pas prévu. D'après ce que j'ai compris, avec l'offre Livebox Max Fibre, si on demande un ONT externe, on se retrouve en GPON limité à 1 Gbps au lieu d'être en XGS-PON.
XGS-PON en avant !Sans avoir d’ONT compatible connu pour l’instant ? Monsieur est joueur ;D
J'appelle Orange demain matin...Grands fous ;)
XGS-PON en avant !
Oui je pense que la question est plus de savoir si quand on passe sur le profil 5 gigas sur l'OLT, il autorise toujours la connexion en GPON... et quelles seraient les vitesses autorisées d'ailleurs dans ce cas ?
Oui je pense que la question est plus de savoir si quand on passe sur le profil 5 gigas sur l'OLT, il autorise toujours la connexion en GPON... et quelles seraient les vitesses autorisées d'ailleurs dans ce cas ?
J'ai cru comprendre que 802.1p=0 par défaut, mais au niveau IP y'a-t-il des règles spécifiques sur certains protocoles/ports (ex. http) ?Pour les protocoles applicatifs, non aucune QoS.
"il existe plein de mécanismes dans la LB pour assurer une qualité maximale. Chose que je ne vois pas dans vos confs ... ni dans les capacités de vos routeurs"
Donc QoS applicative, queuing ? (et si oui avec quelles règles)Quand on voit les scores de la LB sur les tests de bufferbloat on a de quoi douter de la présence de la moindre QoS (et d'autant plus que le CPU de la box est anémique). Bon après rien n'empêche de faire mieux sur son propre matos. Je fais du fq-codel en in et du cake en out. Pas de QoS applicative.
Hello,Bonjour
Je parlais bien de la partie applicative.
Cependant je me permets de maintenir la question car c'est cette phrase en 1ère qui m'a fait m'interroger :
Donc QoS applicative, queuing ? (et si oui avec quelles règles)
A+
Sans avoir d’ONT compatible connu pour l’instant ? Monsieur est joueur ;D
Et puis, depuis le temps qu'on le demande, hein, si ça se trouve, la LBv7 dispose peut être d'un mode bridge 🙂Bonjour
Mais non je ne l'ai pas dit.
@Levieux, tue dans l'oeuf tout espoir de mode bridge, ou deviens une incarnation du messie en nous indiquant si le mode bridge peut devenir réalité.
Cela va pas le faire (le bridge), pour des raisons techniques de notre coté (celles que vous connaissez, on fait l'auth dans le 832 inband)Bridge dans le sens freebox, non.
et pour passer en mode bridge il faudrait le faire en outband dans un autre VC/VLAN (il me semble que Free fait cela pour avoir l'interface d'admin dans le cloud, mais je ne suis pas certain de ce que je raconte là, cela fait longtemps que je me suis pas penché en rétro sur le fonctionnement de la concurrence)Oui c'était le cas sur la freebox V2 en 2003 (ça ne me rajeunit pas). C'est peut-être toujours le cas aujourd'hui.
pourquoi ne pas proposer une deuxième IP sur le /22 en option payante et qui donne une première IP à la LB et laisse une deuxième dispo sur le LAN sur le même principe qu'OBS ?Car ce serait une usine à gaz ? pour pas grand chose (commercialement parlant)
C'est beaucoup plus dans les couches basse d'accès au médium physique, mécanique de détection de perte de liens et connectivité et reprise pour avoir une dispo max.
=> là clairement y'a un manque dans vos solutions. Mais de ce que je lis sur le forum, cela semble convenir à vos usages
Pour le décodeur, il faut lui donner en option DHCP les DNS d'Orange ainsi que l'option 125.
Tu ne parles pas du proxy IGMP. Est-il installé et en service sur ton routeur ? Ceci est nécessaire pour les flux TV.
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o orange -j MASQUERADE
COMMIT
*mangle
:PREROUTING ACCEPT [604:477856]
:INPUT ACCEPT [589:476608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [487:83466]
:POSTROUTING ACCEPT [487:83466]
-A POSTROUTING -o orange -j CLASSIFY --set-class 0000:0001
-A POSTROUTING -o vlantv -p igmp -j CLASSIFY --set-class 0000:0006
-A POSTROUTING -o orange -p igmp -j CLASSIFY --set-class 0000:0006
-A POSTROUTING -o orange -p icmp -j CLASSIFY --set-class 0000:0006
-A POSTROUTING -o orange -m dscp --dscp 0x2e -j CLASSIFY --set-class 0000:0005
-A POSTROUTING -o orange -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i orange -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o orange -j ACCEPT
-A FORWARD -i vlantv -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o vlantv -j ACCEPT
COMMIT
# Completed on Sun Sept 29 09:49 2013Pour IGMP, la CoS doit être à 5 et pas à 6...
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o orange -j MASQUERADE
COMMIT
*mangle
:PREROUTING ACCEPT [604:477856]
:INPUT ACCEPT [589:476608]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [487:83466]
:POSTROUTING ACCEPT [487:83466]
-A POSTROUTING -o orange -j CLASSIFY --set-class 0000:0001
#-A POSTROUTING -o vlantv -p igmp -j CLASSIFY --set-class 0000:0006
#-A POSTROUTING -o orange -p igmp -j CLASSIFY --set-class 0000:0006
-A POSTROUTING -o orange -p igmp -j CLASSIFY --set-class 0000:0005
-A POSTROUTING -o vlantv -p igmp -j CLASSIFY --set-class 0000:0005
-A POSTROUTING -o orange -p icmp -j CLASSIFY --set-class 0000:0006
-A POSTROUTING -o orange -m dscp --dscp 0x2e -j CLASSIFY --set-class 0000:0005
-A POSTROUTING -o orange -p udp --dport 67 -j CLASSIFY --set-class 0000:0006
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -i orange -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o orange -j ACCEPT
-A FORWARD -i vlantv -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o vlantv -j ACCEPT
COMMIT
# Completed on Sun Sept 29 09:49 2013
même si parfois il est bougon, c'pas grave je l'aime aussi, et puis ce forum aussi, toussa, toussa, toussa.Bougon ? Moi Bougon ?
Cela va pas le faire (le bridge), pour des raisons techniques de notre coté (celles que vous connaissez, on fait l'auth dans le 832 inband) et pour passer en mode bridge il faudrait le faire en outband dans un autre VC/VLAN (il me semble que Free fait cela pour avoir l'interface d'admin dans le cloud, mais je ne suis pas certain de ce que je raconte là, cela fait longtemps que je me suis pas penché en rétro sur le fonctionnement de la concurrence)
Changer ça est un truc majeur à faire. Pour un intérêt pour le GP "classique" (je mets pas les gens qui sont sur ce forum dans ce groupe là ...) nulle
J'ai demandé avec insistance d'avoir plusieurs délégation de /64 IPv6 par contre, a suivre (petit espoir si cela intéresse les PRO/PME).
En vrai le bridge on peut s'en passer je pense, le tout qu'il y ait du vrai routage + délégation du /56 (ou un peu moins) perso, ça m’irait très bien et ça ne changerait absolument rien à l’architecture actuelle.
Sinon propose leur une solution à la milkyWAN : du bon vieux PPPoE (que vous avez déjà) avec une MTU relevée pour avoir les 1500 en ethernet avec le DHCPv6-PD dedans... tout serait tellement plus simple.
Le problème du PPPoE est la pénalité sur la performance et ce n'est clairement pas la solution d'avenir avec les débits qui vont continuer d'augmenter. Déjà pour trouver du matériel abordable qui tient le 10 Gbps en PPPoE cela ne court pas les rues, en plus de l'impact sur la consommation d'énergie sur la totalité d'un parc abonné...Bonjour
L'opérateur AT&T aux US utilise du 802.1X pour authentifier ses clients fibre avec un certificat. On retrouve donc les mêmes avantages du RADIUS sur une solution bien plus moderne et Ethernet natif.
Bonjour,
Avec tout les options, penses-tu qu'un Windows Server avec le DHCP pourrait faire office de passerelle internet ?
Je parles pour le "sport" de la chose .
Depuis le 27 février, j'ai l'impression que les équipements Orange de Lyon 3 nécessite la COS 6 (Priority class of service 6) sur le VLAN 832 pour obtenir un bail DHCP.Bonjour
Avant, ça fonctionnait sans modifier la priorité sur le VLAN. Je pense que les équipements ont été mis à jour. J'ai aussi noté un changement du préfixe IPv6 public.