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 29 118.671420 fe80::46d4:54ff:fe1e:96b0 fe80::ba0:bab ICMPv6 90 Neighbor Solicitation for fe80::ba0:bab from 44:d4:54:1e:96:b0
30 118.672936 fe80::ba0:bab fe80::46d4:54ff:fe1e:96b0 ICMPv6 90 Neighbor Advertisement fe80::ba0:bab (rtr, sol, ovr) is at 20:e0:9c:12:b9:5f
44 358.622678 SagemcomBroa_1e:96:b0 Broadcast ARP 64 Who has 90.91.8.1? Tell 90.91.14.94
45 358.623963 Nokia_12:b9:5f SagemcomBroa_1e:96:b0 ARP 64 90.91.8.1 is at 20:e0:9c:12:b9:5f
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://x.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.
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
A l'ICMPv6 code RS issu de la boxe et à destination de l'ipv6 multicast idoine (c'est ba0bab qui répond)
config interface 'wan4'
option proto 'dhcp'
option device 'wan.832'
option hostname '*'
option broadcast '1'
option norelease '1'
option reqopts '1 3 6 15 28 51 58 59 90 119 125'
option clientid '0138xxxxxxxxxx'
option vendorid 'sagem'
option sendopts '77:"+FSVDSL_livebox.Internet.softathome.Livebox6" 90:xxxxxxxxxxxxxxx'
config interface 'wan6'
option proto 'dhcpv6'
option device 'wan.832'
option reqprefix 'auto'
option reqaddress 'none'
option defaultreqopts '0'
option reqopts '11 17 23 24'
option noclientfqdn '1'
option noacceptreconfig '1'
option clientid '0003000138xxxxxxxxxx'
option userclass 'FSVDSL_livebox.Internet.softathome.Livebox6'
dhcp-class-identifier "sagem", user-class "+FSVDSL_livebox.Internet.softathome.Livebox[b]X[/b]", option-90 $1, dhcp-client-identifier 01:$2subnet-mask,broadcast-address,dhcp-lease-time,dhcp-renewal-time,dhcp-rebinding-time,domain-search,routers,domain-name-servers,option-90send-interface "[Interface WAN]", vlan-id 832, vlan-pcp 6ia-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:[b]4c[/b]:69:76:65:62:6f:78:3[b]X[/b], raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d, raw-option 11 $1, raw-option 1 00:03:00:01:$24d2c2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f783X mais j’ai aussi vu la variante plus courte 2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f783Xcette dernière est équivalente à la chaine de raw option 15 sans les :ip l s $IFACE type vlan egress 6:6
# Add PCP 6 (802.1Q prio 6)
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress device $IFACENAME priority 0; }"
nft insert "rule netdev filter egress udp dport { 67, 547 } meta priority set 0:6 comment \"Set CoS value to 6 for DHCPv4/v6 packets\""
table netdev filter {
chain egress {
type filter hook egress device "IFACENAME" priority filter; policy accept;
udp dport { 67, 547 } meta priority set 0:6 comment "Set CoS value to 6 for DHCPv4/v6 packets"
}
}
table netdev filter {
chain egress {
type filter hook egress device "IFACE_NAME" priority filter; policy accept;
icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for RS/RA packets"
udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment "Set CoS value to 6 for DHCPv6 packets"
ether type arp meta priority set 0:6 comment "Set CoS value to 6 for arp packets"
udp dport 67 meta priority set 0:6 ip dscp set cs6 comment "Set CoS value to 6 for DHCPv4 packets"
}
}
# Add PCP 6 (802.1Q prio 6)
nft add "table netdev filter"
nft add "chain netdev filter egress { type filter hook egress device IFACE_NAME priority 0; }"
# IPV4
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6 comment \"Set CoS value to 6 for DHCPv4 packets\""
nft insert "rule netdev filter egress ether type arp meta priority set 0:6 comment \"Set CoS value to 6 for arp packets\""
# IPV6
nft insert "rule netdev filter egress udp dport 547 meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for DHCPv6 packets\""
nft insert "rule netdev filter egress icmpv6 type { nd-router-solicit, nd-neighbor-solicit, nd-neighbor-advert } meta priority set 0:6 ip6 dscp set cs6 comment \"Set CoS value to 6 for RS/RA packets\""
@levieuxatorange pourrais-tu me confirmer quelque chose ?Hello
J'ai l'impression que depuis que je suis passé d'une ligne G-PON à XGS-PON, je n'ai plus "besoin" de passé en prio 6 les packet DHCP. J'obtiens une IP et un bail ipv4/ipv6 avec prio 0 ou avec prio 6 ...
Un changement sur le XGS-PON qui retag auto les packet DHCP en prio 6 vers le server DHCP ?
Hello
Je suis surpris, cela ne devrais pas, je vais passer voir un collègue. Par contre garde quand même le priorité 6, si le DHCP n'est pas priorisé en 6, du trafic internet "de base" sur l'arbre peut faire poubelliser tes trames.
Les arbres sont hyper rarement en saturation, mais cela arrive de temps à autre suivant le comportement des autres "habitants" de l'arbre XGS.
LeVieux
Pour mon cas, si tu veux on peut faire un test. Mais je suis à peu près sur que sur une de mes deux lignes j'étais obligé d'avoir la COS6. Je peux me tromper car ça fait pas mal de temps que j'avais mi en place cela dit.Re
Je peux te filer l'adresse de la ligne en question, si jamais tu veux check le statut en G-PON et ensuite celui en XGS-PON.
Re
J'ai eu la réponse : sur les cartes XGS, suivant le constructeur c'est plus ou moins flexible :
- certain prennent tous les COS
- certain ne fonctionne que sur les COS = 6 / 7 (pour la descente)
Et plutôt que de faire des ingénierie complexe, on colle au comportement de base du constructeur.
Comme aucune certitude du constructeur en face et que cela peut changer suivant les réorganisations réseau, rester sur la COS6 comme indiqué.
LeVieux
J'ai toujours cru que la COS dépendait du BNG et non des cartes de l'OLT.
Ça veut donc dire que même sur les GPON c'est elles qui jettent les requêtes si c'est pas à la bonne prio ?
J'ai toujours cru que la COS dépendait du BNG et non des cartes de l'OLT.
Ça veut donc dire que même sur les GPON c'est elles qui jettent les requêtes si c'est pas à la bonne prio ?
Mais du coup le mdp associé au fti on le trouve ou ?A l'époque où j'ai souscrit chez Orange (en 2016), le mot de passe était envoyé par courrier si ma mémoire est bonne. Depuis Orange fait de l'autoconfiguration de la box à la première connexion, et j'avoue ne pas savoir comment récupérer le mot de passe...
A l'époque où j'ai souscrit chez Orange (en 2016), le mot de passe était envoyé par courrier si ma mémoire est bonne. Depuis Orange fait de l'autoconfiguration de la box à la première connexion, et j'avoue ne pas savoir comment récupérer le mot de passe...
Pendant un temps il était également disponible sur le site web du service client, mais je viens de regarder, il n'y est plus non plus (où alors si bien caché que je ne l'ai pas trouvé). Reste donc l'appel au 3900...
Pour moi c'est un choix délibéré pour mettre les bâtons dans les roues des nouveaux clients qui veulent se passer de box.
Et du coup il y a quoi dans l’option 90 ?…
Orange est tout à fait capable de vérifier le mot de passe dans l’option 90: Le mot de passe du client est en clair dans le SI, ils ont accès au salt généré par la box. Ils peuvent donc tout à fait calculer le hash de leur côté et le comparer au hash envoyé par la box.
Et c’est d’ailleurs ce qu’ils font puisque si je mets un mauvais mot de passe lors de la génération de l’option 90 je n’ai plus de connexion.
Franchement je ne vois pas pourquoi ils se seraient emmerdés à faire du développement spécifique dans la box pour gérer l’option 90 si au final ils ne vérifient pas le hash (et les documents internes auxquels j’ai eu accès indiquent clairement que la volonté est bien de réintroduire la vérification du mot de passe en DHCP).
Ok merci du coup je dois passer par l'appel au 3900.
L4argument je veux me passer de la livebox est recevable coté Sosh ?
L'argument du: il y a un password, donnez moi le password, période.Je suis intéressé de savoir si il le donne et surtout comment
Je suis intéressé de savoir si il le donne et surtout comment
Normalement pas à l'oral, uniquement par SMS sur le portable de contact renseigné depuis qq temps dans le compte client.
Ou par courrier papier à l'adresse de facturation.
L'argument du: il y a un password, donnez moi le password, période.En effet ils m'ont donné le mot de passe via chat sans difficulté (via le 3900 j'ai pas réussi à avoir un humain...)
Bonjour,
Il y a eu des changements sur l'icmp packet to big ?
Il ne passe plus chez moi sur le réseau Orange.
Ok chez moi (en ADSL).
Au début, j'ai cru que ça bugait aussi car je ne voyais plus les NS/NA et RA, mais ils sont super espacés (toutes les 2 min environ), aussi je trouvais bizarre que ça continue à fonctionner sans.
En effet ils m'ont donné le mot de passe via chat sans difficulté (via le 3900 j'ai pas réussi à avoir un humain...)
@levieuxatorange je t'ai décris le process en MP
Merci pour l'aide
Je suis dans une maison de vacance :-) avec 16 personnes donc je limite les coupures reseaux ;-)
Je fait une tentative nouvelle tentative demain
Le tcpdump (je ne suis pas expert) je lui donne des arguments pour restreindre ce qu'il recupere?
Coté log j'ai rien vu de significatif
Par contre je ne recupere pas la gateway via DHCP.Pourtant elle est bien dans la réponse du serveur DHCP. Le problème est donc sur le pfSense.
Les règles nécessaires ne sont pas déjà dans le tutorial ?
La dernière fois que j'ai touché de l'OPNSense, ICMPv6 était autorisé par défaut. Pareil pour pfsense, mais ca fait ~6-7 ans que j'ai essayé.
rc.bootup: Gateway, NONE AVAILABLE
rc.bootup: The command '/sbin/route -n6 get 'default' 2>/dev/null | /usr/bin/egrep 'flags: <.*PROTO.*>'' returned exit code '1', the output was '' Ce qui fait que "mon adresse" a un "01:" en plusNormal et nécessaire en IPv4.
Dans quelle mesure cette IP bouge t'elle et pour quelle raison ou a quelle frequence?LeVieux a déjà répondu autre part il me semble : de mémoire, l'IPv4 et le /56 IPv6 peuvent changer dès qu'une réorganisation réseau est réalisée (déplacement de l'arbre PON sur une autre carte OLT ou sur un autre OLT, renumbering des pools DHCP, etc.) et potentiellement une fois tous les ans pour une raison obscure.
reste t'elle dans la meme plage (avec une gateway identique?)Aucune garantie de ce côté là à mon avis.
Que pense tu de mettre une debian sur une HW netgate ARM ? (pas a distance bien sur..; mais au Noel prochain ;-) n'allons pas passer d'un pb de gateway a un autre pb de HW proprietaire spécifique pas forcement bien géré par Debian?Quel modèle ? J'ai installé freebsd sans souci sur des SG-1000 32-bit, ca a fonctionné des années sans souci. Les nouveaux modèles sont 64 bit, probablement mieux supportés par linux.
Merci Simon pour les infos sur l'IP
Donc ca ne bouge pas tout le temps non plus...
Le Hw en question est un netgate 2100 : CPU: Dual core ARM v8 Cortex-A53 1.2 GHz
Bonjour,
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.
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.
Laurent
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.
En mettant le VLAN à 6 directement ça à l'air de fonctionner pour le DHCP mais ça impacte le débit fortement... Vous avez déjà eu ce problème ?
Si tout le traffic sortant dans le VLAN 832 est taggué en priorité 6, ce traffic est priorisé par le réseau Orange. Pour que les gens n'en abusent pas, ils limitent forcément le débit autorisé pour les classes de traffic priorisées.
Il faut donc en effet le repasser à 0, et chercher à ne passer en CoS 6 que les requetes DHCP, ARP et Neighbor Discovery/Neighbor Advertisement.
Il faut donc en effet le repasser à 0, et chercher à ne passer en CoS 6 que les requetes DHCP, ARP et Neighbor Discovery/Neighbor Advertisement.Pour ma part je n'ai jamais remarqué d'anomalie ou de blocage si l'ARP ou ND/NA est en CoS=0.
Pour ma part je n'ai jamais remarqué d'anomalie ou de blocage si l'ARP ou ND/NA est en CoS=0.Moi non plus. Je ne l'ai jamais fait pendant longtemps (difficile à mettre en oeuvre sur un EdgeRouter avant les firmwares 2.x). Maintenant j'ai un switch manageable entre mon routeur et mon ONT qui s'occupe de toute la CoS 802.1p (et du DSCP aussi du coup).
(ce qui ne veut pas dire qu'il ne faut pas le faire).
Quelqu'un aurait-il à ce jour constaté un contrôle sur ce type de trafic ?
Moi non plus. Je ne l'ai jamais fait pendant longtemps (difficile à mettre en oeuvre sur un EdgeRouter avant les firmwares 2.x). Maintenant j'ai un switch manageable entre mon routeur et mon ONT qui s'occupe de toute la CoS 802.1p (et du DSCP aussi du coup).Je pense à ça car Mikrotik aurait prévu prochainement une option dédiée du client DHCP permettant de spécifier la CoS VLAN.
À priori ca dépend des OLT/routeurs de collecte auquel tu es connecté. Chez moi, je n'en ai pas besoin.Chez moi la CoS est vérifiée, mais l'ARP/ND-NA ne l'est pas.
La non-application de la CoS 6 sur ND et ARP n'a jamais posé de souci de connectivité, tout comme le non marquage DSCP.Hello
Le non marquage de la COS 6 pour ARP et ICMP ne bloque pas la connectivité effectivement.Hello levieuxatorange, et merci pour la précision.
C'est en cas de surcharge de l'arbre XGS/G-PON (cas très rare cependant ...) que cela peut poser soucis : si plus de 3 échanges ARP/ICMP sont perdus entre la LB et le BNG, le lien sera considéré comme perdu et il y aura déconnexion par le BNG.
Normalement la LB le fait aussi, mais dans votre cas c'est pas une LB ...
Hello
Le non marquage de la COS 6 pour ARP et ICMP ne bloque pas la connectivité effectivement.
C'est en cas de surcharge de l'arbre XGS/G-PON (cas très rare cependant ...) que cela peut poser soucis : si plus de 3 échanges ARP/ICMP sont perdus entre la LB et le BNG, le lien sera considéré comme perdu et il y aura déconnexion par le BNG.
Normalement la LB le fait aussi, mais dans votre cas c'est pas une LB ...
LeVieux
Depuis que j'ai remplacé ma LB par Opnsense, je perts l'accès à la gateway tous les deux/trois jours environ. Une relance de l'interface règle le problème,Bonjour
Depuis que j'ai remplacé ma LB par Opnsense, je perts l'accès à la gateway tous les deux/trois jours environ. Une relance de l'interface règle le problème, c'est peut être une bonne piste. Reste à voir comment marquer uniquement l'ARP et l'ICMP en cos6 sur opnsense :)Si tu peux le faire facilement, en effet, marquer ARP et ICMPv6 link-local en CoS6 peut être pas mal. Je suis cependant quasi-sûr que c'est un souci de renew DHCP comme le dit LeVieux.
Hello,
je repost dans ce sujet vu que j'ai posté dans le mauvais (spécifique mikrotic)
orange m'a informé d'une coupure la nuit dernière entre 4h et 6h.
Coupure effective, mais à 6h pas de retour. Je tente un reboot de mon router openwrt, rien n'y fait il n'obtient rien. Vers 8h je décide de rebrancher ma livebox. Qui se connecte et arrive à se connecter. Je reçois alors un texto m'informant que l'intervention est terminée. Donc soit orange attendait d'avoir un acquittement de la LB pour confirmer la fin de l'intervention, soit c'est du pur hasard (SMS reçu à 08:02 CEST alors que le SMS indiquait une fin d'intervention à 06:00 (sans spécifier la timezone, donc on pourrait penser à de l'UTC ce qui colle aux 2h de différences). Bref mistère.
Au final je rebranche mon routeur qui retrouve une connexion IPv4 sans problème, mais pas d'IPv6.
le DHCP me répond NoPrefixAvail :-(
tout fonctionnait parfaitement depuis plusieurs mois et là une intervention et ça ne fonctionne plus.
Qu'est ce qui aurait pu changer ?
The IAID uniquely identifies the IA and MUST be chosen to be unique among the IAIDs for that IA type on the client (e.g., an IA_NA with
an IAID of 0 and an IA_PD with an IAID of 0 are each considered unique).
je me répond à moi même. j'ai débranché la fibre 30' le temps du petit dej et à la reconnexion c'est revenu.
C'est juste le changement de hardware qui nécessite une pause (30' est certainement trop long).
bref en tout cas c'est reparti.
Deux clients DHCP peuvent avoir le même IAID mais n'auront pas pour autant la même liaison dans le serveur DHCP.
De l'importance des tests de vie :
La connexion de la LB peut être interrompue sur plusieurs segments entre la LB et le BNG.
Si vous ne testez pas la connexion montante, vous allez vous retrouver hors séquence et donc vous faire blaster régulièrement.
Cela doit être fait sur LES DEUX stacks Ipv4 et IPv6
Une capture minimal de ce que fait la LB vous permettra de comprendre la puissance de ces deux algos ....
Et quand vous détectez une fin de vie sur un stack, vous relancez celui ci (cycle DORA ou SARR suivant le stack) proprement
Faite un RELEASE (du bon stack) AVANT de relancer le cycle ....
Durant votre capture, vous verrez que le BNG fait de même dans l'autre sens ... d'où l'importance de bien répondre à ces message avec la bonne COS6
@simon :
Je ne pense que ce soit cela l'explication.
Je pense plutôt que @fatpat a imaginé que l'intervention programmée de Orange était à l'origine du problème. Ensuite, il l'a assimilé à quelque chose de similaire à un changement de matériel.
Sa justification par rapport au changement matériel est tirée par les cheveux, car c'est potentiellement du côté opérateur que le changement a été enclenché.
CF le poste pour la cos6 + dscp avec nftable.DSCP n'est nécessaire nulle part, il me semble.
C'est pour le moment la seule solution complète et totalement testé qui répond aux spec que suit orange.
When you switch hardware (new router / ONU / ONT) you have to wait a few minutes with DISCONNECTED fiber link. DHCP IAID are dynamically generated by hardware equipments and Orange is waiting for a single IAID per client.
To force expiration, the only way is to disconnect fiber 15-30 minutes and wait… The issue is that you will NOT get DHCPv6 prefix (NoPrefixAvail) from Orange.
Eh bien encore une fois, très probablement parce que l'adresse MAC utilisée par la Livebox et son routeur OpenWRT (sur sa patte WAN) ne sont pas les mêmes.
6.6. Multiple Addresses and Prefixes
[...]
The same principle also applies to prefix delegation. In principle, DHCP allows a client to request new prefixes to be delegated by sending additional IA_PD options (see Section 21.21).
However, a typical operator usually prefers to delegate a single, larger prefix. In most deployments, it is recommended that the client request a larger prefix in its initial transmissions
rather than request additional prefixes later on. The exact behavior of the server (whether to grant additional addresses and prefixes or not) is up to the server policy and is out of
scope for this document.
De l'importance des tests de vie :
La connexion de la LB peut être interrompue sur plusieurs segments entre la LB et le BNG.
Si vous ne testez pas la connexion montante, vous allez vous retrouver hors séquence et donc vous faire blaster régulièrement.
Cela doit être fait sur LES DEUX stacks Ipv4 et IPv6
Une capture minimal de ce que fait la LB vous permettra de comprendre la puissance de ces deux algos ....
Et quand vous détectez une fin de vie sur un stack, vous relancez celui ci (cycle DORA ou SARR suivant le stack) proprement
Faite un RELEASE (du bon stack) AVANT de relancer le cycle ....
Durant votre capture, vous verrez que le BNG fait de même dans l'autre sens ... d'où l'importance de bien répondre à ces message avec la bonne COS6
Dans le cas d'un changement de matériel, cela devient effectivement problématique. Néanmoins, on ne le fait que rarement (sauf lors de la phase de mise au point).Bonjour
Idem ici, leasetime de 259200 s. Et je ne sais pas si c'est lié, mais y'a 3 jours mon routeur a reboot tout seul et j'ai aussi récupéré les DNS en IPv6.
Bonjour,
Juste une question métaphysique :
sur le dhcpv4 client, le délai d'expiration de l'IPv4 est passé de 7 jours à 3 jours ?
sur le dhcpv6 client, même chose, délai du préfix passé de 7 jours à 3 jours ?
Je n'ai rien changé sur mon routeur (CCR2004), c'est arrivé hier ou avant-hier (je n'ai pas le nez toujours dedans !)
Des idées ? ???
merci d'avance ...
Cordialement
reboot de routeur ? Si c'est une livebox je veux bien, sinon c'est pas lié ou étrange :) mais oui, ils se sont probablement mis à pousser des DNS en IPv6. Je ne les utilise pas alors je ne sais pas si je les recois ou pas (j'ai un resolveur local).
Ca fait assez longtemps que le lease time est à 259200sec (72h / 3j)
Le renew est entre ~60000s et ~90000s
C'est le renew qu'il faut respecter pour le renouvellement de la lease DHCP pas le lease time. Normalement vous devriez faire un renew toutes les 17-25hrs
Pas pour moi (et je ne suis pas le seul...) le lease time (depuis les changements importants relatés dans ce fil) est à 604 800 secondes (7 jours)
le renewal (T1) à 84672 secondes.
Bonsoir,
Pas pour moi (et je ne suis pas le seul...) le lease time (depuis les changements importants relatés dans ce fil) est à 604 800 secondes (7 jours)
le renewal (T1) à 84672 secondes.
Malheureusement, RouterOS ne sait pas traiter ce renewal, et le renew se produit à la moitié du bail : 3,5 jours.
Le prochain renew est donc maintenant au bout de 1,5 jour.
Dans la version qui arrive (la 7.17) le T1 va enfin fonctionner (enfin, Mikrotik dixit...)
Normal: la durée du renew en DHCPv4 est liée à la durée du bail (1/2 durée du bail +- un temps aléatoire).Non, dans les 2 cas (IPv4 et IPv6), Orange diffuse un renewal-time d'un peu moins de 24h (850xx secondes chez moi en ce moment , mais ce temps diffère selon le bail), il doit donc y avoir un renew tous les jours toutes les 855xx s autant en IPv4 et IPv6, indépendamment de la durée du bail ou moitié du bail.
En IPv6, ce sont les timers T1 et T2 qui contrôlent la fréquence des renew, et ces valeurs sont disjointes de la durée du bail.
Tu pourras voir en IPv6 que ton bail est également passé à 3j, mais je ne connais pas Unifi. Si c'est bien fait, le valid lifetime des adresses configurées sur les stations devrait refléter ces 3j.
Non, dans les 2 cas (IPv4 et IPv6), Orange diffuse un renewal-time d'un peu moins de 24h (850xx secondes chez moi en ce moment , mais ce temps diffère selon le bail), il doit donc y avoir un renew tous les jours toutes les 855xx s autant en IPv4 et IPv6, indépendamment de la durée du bail ou moitié du bail.
Si ce n'est pas le cas, c'est un bug du client dhcp sur votre appareil.
root@UCG-Max:~# /usr/bin/busybox-legacy/udhcpc --help
BusyBox v1.34.1 (2024-05-30 00:25:15 CST) multi-call binary.
ethertype 802.1Q (0x8100), length 448: vlan 832, p 6, ethertype IPv4 (0x0800), (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 430)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 2c:xx:xx:xx:xx:xx, length 402, xid 0x6875413f, Flags [none] (0x0000)
Client-Ethernet-Address 2c:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Vendor-Class (60), length 5: "sagem"
Client-ID (61), length 7: ether 2c:xx:xx:xx:xx:xx Hostname (12), length 8: "OPNsense"
Parameter-Request (55), length 12:
Subnet-Mask (1), BR (28), Lease-Time (51), RN (58)
RB (59), Unknown (119), Default-Gateway (3), Domain-Name-Server (6)
AUTH (90), Domain-Name (15), Unknown (120), Unknown (125) User-Class (77), length 44: instance#1: "FSVDSL_livebox.Internet.softathome.Livebox4", length 43
AUTH (90), length 70: 0.0.0.0.0.0.0.0.0.0.0.22.9.0.0.5.00.1.3.22.1.13.000.116.111.00.22.117.111.116.33.52.55.00.22.66.50.00.00.53.54.55.56.00.48.00.50.51.66.53.33.3.19.33.205.000.25.50.333.30.444.121.88.203.444.444.33.11.44.555
ethertype IPv4 (0x0800), length 441: (tos 0xc0, ttl 64, id 39958, offset 0, flags [none], proto UDP (17), length 427)
80.10.234.145.67 > 193.253.xxx.xx.68: [udp sum ok] BOOTP/DHCP, Reply, length 399, xid 0x6875413f, Flags [none] (0x0000)
Your-IP 193.xxx.xxx.xx
Server-IP 80.10.234.145
Gateway-IP 80.10.234.145
Client-Ethernet-Address 2c:xx:xx:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Server-ID (54), length 4: 80.10.234.145
Lease-Time (51), length 4: 259200
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 193.253.xxx.255
Default-Gateway (3), length 4: 193.253.xxx.1
Domain-Name-Server (6), length 8: 80.10.246.136,81.253.149.6
Client-ID (61), length 7: ether 2c:xx:xx:xx:xx:xx
Hostname (12), length 8: "OPNsense"
AUTH (90), length 27: 0.0.0.0.0.0.0.0.0.0.0.100.555.99.112.111.105.118.111.98.111.120.102.111.50.53.22
Unknown (125), length 17: 0.0.5.88.12.1.10.0.1.0.0.0.0.0.0.0.0
Unknown (119), length 34: 848,21844,1633,25443,25971,29457,28530,24942,26469,11629,30060,29801,28005,25705,24835,28261,29696
RN (58), length 4: 78817
RB (59), length 4: 207360
D'après les lecture j'entends parler de COS? à quoi ça correspond dans OPNSense?Manifestement ça c’est déjà bon, c‘est le « p 6 » dans ta première capture.
Certains retagguent en VLAN Priority 6, les paquets sortant vers le port 67 via le firewall, mais comment? quel config avec OPNSense?
Et en fait non, et je n'ai même pas d'option 125 de retour. Comme si le module XGS-PON n'était pas O5.
...
Le stick FS ne se suffit pas a lui seul, tu dois le modifer comme je l'explique ici :
- https://lafibre.info/remplacer-livebox/xgs-pon-remplacement-de-la-livebox-7-10gbe/
- https://akhamar.github.io/orange-xgs-pon/
Si pas déjà fait.
Si besoin je peux t'aider sur discord, étant donné que tu es déjà dessus :)
Unknown(125) = 00-00-05-58-0C-01-0A-00-01-00-01-99-00-00-00-00-00ça maaaarche :D
Le souci était que le module FS est un module presque. Il te fait croire qu'il est O5, mais en fait non. Il est pénible, pour un rien de reboot trop rapide il oublie sa configuration.
Il m'a fait perdre mon temps deux semaines.
Vade retro matos raté.
Bonjour
Quand on a monté le projet transition IPv6 pour le réseau Orange Fixe la vision que l'on avait (partagé uniquement entre les techniques) c'est :
- réseau Dual Stack très très long terme.
- apparition de service IPv6 only pour le GP vers 2030. Généralisation assez rapide des IPv6 Only pour les gros service GP rapidement après.
[...]
- début CGN (IPv6 Only à la Boxe + DS-LITE ou autre solution technique pour trouver le "Web" IPv4) vers 2025, généralisation vers 2030 (lié à l'apparition des premiers services IPv6 Only)
J'y crois peu... tu auras toujours de l'IPv4 sur la patte LAN de la box, et de surcroit, tu pourras demander une IPv4 publique non-partagée.Techniquement en DS-LITE :
Ceux qui ne veulent pas migrer vont cocher la case et faire comme avant, j'ai bien peur.
- il sera possible de demander explicitement à être dans le CGN.
Si cela intéresse, je pourrais vous compléter la partie définition protocolaire de ce thread avec la partie spec du CGN DS-LITE.
Est-ce que ce sera lié à l'abonnement (donc vérification/gestion côté réseau) ou juste par la box (avec cette case CGN) ?Combinatoire entre plusieurs choses : abonnement, boxe, configuration cliente
Oui, bien sûr, les détails de config DS-Lite nous intéressent :-)
La plus grosse transfo que je vois arriver c'est que le p*rn, le hack et l'accès au darkWeb devrait lui basculer en Ipv6 là où jusqu'a présent rien ne bouge (où pas beaucoup).
Pour mon info, qu'est ce qui te fait penser que le p*rn et le hack devraient basculer en v6 à cause du déploiement de DS-Lite?
Pour le p*rn, est-ce que ca serait à cause de l'impact de perf lié à l'encapsulation et au CG-NAT ? (+ le fait que le CG-NAT sera probalement localisé sur un ou deux sites uniquement)
Pour le hack, j'ai plus de mal à voir.
Cette case permettra en effet de ne pas entrer dans la mécanique DS-LITE. Ici de manière explicite. Y'a d'autres raison pour lesquels coté Orange un client ne sera pas dans la partie CGN.
Par contre, rien n'empêchera de passer dans le futur à une mécanique DS-LITE obligatoire (bon j'y crois pas avant 2029 la partie obligatoire)
Ma question s'adressera plutôt aux courageux qui veulent tenter l'aventure de la migration un cran plus loin vers IPv6 "presque Only" avec la feature CGN pour l'IPv4 pour les morceau du WEB qui ne font pas encore de Ipv6 (spéciale @vivien celle là :))Quand je vois le peu de traffic IPv4 qui sort de mon interface NAT64, je suis presque tenté de désactiver DHCPv4 sur ma patte WAN et d'utiliser les préfixes de https://nat64.net/ .
Pour la "Neutralité du Net", le CGN ne change strictement rien. Que tu fasse ton NAT44 en local de ta boxe ou à distance dans le CGN c'est exactement la même mécanique. (@Mastah)Je suis pas entièrement d'accord. En faisant du NAT tu ne peux plus toi même configurer le forward de port et donc tu ne peux donc plus rien héberger chez toi accessible de l'extérieur. Ca fonctionne effectivement pareille, mais tu n'es plus maitre de la config.
Si je comprend bien le reste de ton explication, c'est que la valeur/comportement par défaut lorsque l'on est pas une "livebox" sera d'avoir une IPV4 attribuer uniquement que pour nous ?Bonjour
d'ici là , la téléphonie fonctionnera en IPV6Je confirme,
Bonjour
Je confirme, sans action, on garde un DualStack Full.
Donc ceux qui n'ont pas de Boxe, sans action spécifique, pas de changement
LeVieux
d'ici là , la téléphonie fonctionnera en IPV6
Plusieurs choses :
EDIT : De ce que j'ai lu, le DS-lite classique grossit assez mal vu que tout est réalisé dans l'AFTR. Il y aura une forte régionalisation je suppose pour répartir la charge ? À moins que ça ne soit plus d'actualité avec le matos actuel ? C'est quel équipement qui va réaliser la fonction d'ailleurs ? ba0bab ou un autre ?
Le réseau local peut-il fonctionner en « IPv6-mostly » avec du Dual-Stack Lite ?
Il peut, mais c'est plus compliqué : il faut que le routeur (CPE/box) embarque un NAT64 et une interface DS-Lite.L'idée c'est plutot d'avoir un vrai DualStack dans le LAN, sur le réseau local.
L'idée c'est plutôt d'avoir un vrai Dual Stack dans le LAN, sur le réseau local.
Sur le WAN opérateur, l'avantage c'est que tu fais que de l'IPv6, donc dans l'optimisation des flux tu n'as qu'un seul protocole à équilibre / trimbaler / surveiller.
Il peut, mais c'est plus compliqué : il faut que le routeur (CPE/box) embarque un NAT64 et une interface DS-Lite.
Je ne vais pas me rendre les choses plus difficiles et faire encore plus compliqué. Autant rester en double pile : IPv4 + IPv6 sur le CPE. ;)Coté LAN, effectivement je te conseille.
Plusieurs choses :
- c'est pas BOBAB qui bosse sur la fonction AFTR
- l'AFTR grossit mal verticalement (un seul plus gros AFTR) car effectivement il fait quand même beaucoup de chose
- par contre y'a aucune difficulté à faire une croissance horizontale
- et y'a aucune difficulté à faire une répartition dynamique entre les clients et les AFTR. Cela peut même se faire à chaque reco en IPv6 si la conf du CPE est suffisamment bien faite.
- et séparer la fonction AFTR des BNG permet de prévoir une répartition optimale: optimiser le placement des AFTR avec l'archi réseau et l'acheminement. En déployer plus. Les résorber quand cela sera le moment.
Remarque : tout ce que j'écris là peut très bien se faire avec d'autre techno (MAP, ...) mais je n'en n'ai aucune idée jamais regardé.
Pour ceux qui veulent tenter le DS-LITE, y'a des truc à base de 100% Linux et des espaces de nommage et routage du noyau. C'est même une assez bonne implémentation de référence je trouve.
Y'a 60 lignes de conf shell pour mettre cela en place d'un client Ipv6 Only en DSLITE, l'AFTR et le répondeur
LeVieux
echo "1 dslite1" >> /etc/iproute2/rt_tables ça devrait marcher.#!/bin/bash
set -o nounset # Exit if trying to use an uninitialized variable
set -o errexit # Exit on any command failure
# Source the configuration file
CONFIG_FILE="/etc/default/dslite-server"
if [ -f "$CONFIG_FILE" ]; then
source "$CONFIG_FILE"
else
echo "Configuration file $CONFIG_FILE not found. Exiting."
exit 1
fi
# Apply default values if variables are empty
LOCAL_HOST="${LOCAL_HOST:-aftr.example}"
REMOTE_HOST="${REMOTE_HOST:-remote.example}"
TUN_IP4="${TUN_IP4:-192.0.0.1/29}"
TUN_NET="${TUN_NET:-192.0.0.0/29}"
TUN_IFACE="${TUN_IFACE:-ip4tun0}"
WAN_IFACE="${WAN_IFACE:-eth0}"
# Using same MTU as OpenWrt
#MTU="${MTU:-1280}"
MTU=1460
# MSS is MTU - IP Header size - TCP header size
MSS=$(($MTU - 20 - 20))
get_ipv6() {
host "$1" | grep -i ipv6 | rev | cut -d ' ' -f 1 | rev
}
LOCAL_ADDR=$(get_ipv6 "$LOCAL_HOST")
# Only perform REMOTE_ADDR lookup if not set in the configuration file
REMOTE_ADDR="${REMOTE_ADDR:-$(get_ipv6 "$REMOTE_HOST")}"
echo "IP for $LOCAL_HOST is $LOCAL_ADDR"
echo "IP for $REMOTE_HOST is $REMOTE_ADDR"
echo "WAN interface is $WAN_IFACE, tunnel interface is $TUN_IFACE"
iptables_rule() {
local action="$1"
local rule_suffix="$2"
# Allowing NAT
eval iptables -t nat "$action" POSTROUTING ! -d "$TUN_NET" -o "$WAN_IFACE" -j MASQUERADE $rule_suffix
# Allowing forwarding between interfaces
eval iptables "$action" FORWARD -i "$TUN_IFACE" -o "$WAN_IFACE" -j ACCEPT $rule_suffix
eval iptables "$action" FORWARD -i "$WAN_IFACE" -o "$TUN_IFACE" -m state --state ESTABLISHED,RELATED -j ACCEPT $rule_suffix
eval iptables "$action" FORWARD -i "$WAN_IFACE" -o "$WAN_IFACE" -d "$TUN_NET" -j ACCEPT $rule_suffix
# Allowing inbound traffic
eval iptables "$action" INPUT -i lo -s "$TUN_NET" -d "$TUN_NET" -j ACCEPT $rule_suffix
eval iptables "$action" INPUT -i "$TUN_IFACE" -s "$TUN_NET" -d "$TUN_NET" -j ACCEPT $rule_suffix
# Applying clamping
#eval iptables "$action" FORWARD -o "$TUN_INET" -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss "$(($MSS + 1)):65535" -j TCPMSS --set-mss "$MSS"
#eval iptables -t nat "$action" PREROUTING -i "$TUN_INET" -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m tcpmss --mss "$(($MSS + 1)):65535" -j TCPMSS --set-mss "$MSS"
# Allowing receiving packets from the public endpoint
eval ip6tables "$action" INPUT -s "$REMOTE_ADDR" -j ACCEPT $rule_suffix
# Enable LAN packets marking
eval iptables -t mangle "$action" PREROUTING -i "$TUN_IFACE" -j MARK --set-mark 1
eval iptables -t mangle "$action" POSTROUTING -j CONNMARK --save-mark
eval iptables -t mangle "$action" PREROUTING -j CONNMARK --restore-mark
}
start_tunnel() {
# Without this there is no forwarding
sysctl -w net.ipv4.ip_forward=1
ip -6 tun add "$TUN_IFACE" mode ipip6 local "$LOCAL_ADDR" remote "$REMOTE_ADDR"
ip link set dev "$TUN_IFACE" up
ip link set dev "$TUN_IFACE" mtu $MTU
ip a add "$TUN_IP4" dev "$TUN_IFACE"
iptables_rule "-I" ""
ip route add default dev "$TUN_IFACE" table dslite1
ip rule add fwmark 1 iif "$WAN_IFACE" table dslite1
echo "ds-lite server is up"
}
stop_tunnel() {
ip link del "$TUN_IFACE" || true
iptables_rule "-D" "|| true"
rmmod ip6_tunnel || true
ip route del default dev "$TUN_IFACE" table dslite1
ip rule del fwmark 1 iif "$WAN_IFACE" table dslite1
echo "ds-lite server is down"
}
case "$1" in
start)
start_tunnel
;;
stop)
stop_tunnel
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
;;
esacPour info, voici ce que mon Mikrotik loggue depuis... un certain temps (edit: Le 6 Janvier):
mtu 1540 on V832-ORANGE from fe80::ba0:bab
Donc ba0:bab annonce une MTU de 1540 au lieu de 1500, et 1540 c'est exactement la MTU nécessaire pour faire du DS-Lite selon la RFC 6333.
D’ailleurs la MTU à 1540 (ou autre valeur supérieure) ça se passe comment pour la prise en compte côté client ? J'ai testé l'autre fois avec des VM (debian-radvd/openwrt), mais ça n'avait pas l'air de fonctionner.
Il faut que l'interface se reconfigure avec une MTU plus élevée je suppose ? J'imagine que ça marche sans modif quand on annone une MTU plus basse que 1500.
Ne SURTOUT PAS mettre vos paquets hors DS-LITE à 1540. 99% de chance de subir une fragmentation plus loin sur le réseau et donc de voir un écroulement de la perf.Ca "peut" marcher à peu près si le PMTU Discovery n'est pas bloqué, mais comme c'est de l'ICMP et qu'il y a plein d'admins réseaux qui n'y comprennent rien et qui bloquent TOUT l'ICMP il vaut mieux ne pas parier sur le fonctionnement du PMTU Discovery...
ATTENTION
La MTU "internet" est toujours à 1500 (grosso modo)
La MTU 1540 est la bonne pour aller jusqu'a l'AFTR qui assurera le DS-LITE
Ne SURTOUT PAS mettre vos paquets hors DS-LITE à 1540. 99% de chance de subir une fragmentation plus loin sur le réseau et donc de voir un écroulement de la perf.
LeVieux
Donc selon toi il faut mieux laisser la patte WAN à 1500, tant pis pour les erreurs liées à la MTU ?La patte WAN, tu peux la mettre à 1540 si tu vises à mettre en place le DS-LITE.
La patte WAN, tu peux la mettre à 1540 si tu vises à mettre en place le DS-LITE.
Si ce n'est pas le cas, tu la laisses à 1500.
Mais dans tous les cas, sur ton LAN, les pattes des tes machines qui vont causer à internet ou recevoir des connexions internet tu les laisses à 1500 ...
Si tu veux faire du Jumbo en local de ton LAN, il vaut mieux le faire dans une autre interface.
Tu peux faire sur une seule interface, mais là y'a des points de négo de MTU (voir les autres messages) qui doivent bien être en place.
LeVieux
Et côté routeur, il faut aussi que son trafic ipv6 soit à 1500 excepté le DS-lite, non ?Si la patte LAN de ton routeur est à 1500, tu peux mettre 1540 coté WAN, la patte LAN de ton routeur limitera à 1500 la MTU IPv6
J'ai un doute sur comment configurer ça par contre. iptables ?
Donc c'est bien ce que je disais au départ : le trafic ipv6 émis par le routeur lui-même SANS DS-lite va être aussi à 1540.Là tu t'embetes pas :
C'est ce cas là que je me demande comment on le traite pour le ramener à 1500.
Pour la co IPv4 entrante (@renaud07) y'a deux choses possibles :
- c'est une co "on the fly" et là y'a un protocole (me souviens jamais de l'acronyme) qui fait parti du lot pour ce genre de truc en DS-LITE => là pas gênant.
Cela marche très bien pour tout un tas de cas.
- c'est une co de type "auto hébergement" avec ouverture d'un port spécifique et là cela pose soucis pour le partage d'@IPv4, y'a pas de raison que ceux avec qui tu pourrais partager ton IP ne veulent pas faire strictement là même chose.
Là je dirais qu'il faut commencer à faire cela en IPv6 (c'est ce que moi je fais)
LeVieux
c'est une bonne question … je n'ai jamais été dans ce cas, de mémoire. essaye, au pire tu auras perdu 15min sans net ;-)
Autrement dit, déporter le "dyndns" du routeur sur chacune les machines finales.Le script sur le routeur c'est quand même le plus simple, même en IPv6, vu que le routeur, lui, il sait quand le préfixe change. Pendant très longtemps j'ai utilisé un script perso sur mon Mikrotik qui construisait une adresse IPv6 complète à partir du préfixe reçu et d'un suffixe "fixe", le tout dans une table (1 ligne par enregistrement DNS à mettre à jour). Mes noms de domaines sont hébergés chez Cloudflare.
c'est une bonne question … je n'ai jamais été dans ce cas, de mémoire. essaye, au pire tu auras perdu 15min sans net ;-)
Le script sur le routeur c'est quand même le plus simple, même en IPv6, vu que le routeur, lui, il sait quand le préfixe change. Pendant très longtemps j'ai utilisé un script perso sur mon Mikrotik qui construisait une adresse IPv6 complète à partir du préfixe reçu et d'un suffixe "fixe", le tout dans une table (1 ligne par enregistrement DNS à mettre à jour). Mes noms de domaines sont hébergés chez Cloudflare.
Maintenant je n'ai plus ce problème, j'ai un /48 IPv6 fixe (un tunnel L2TP chez Milkywan).
3.3. Static and Dynamic Assignment
The prefix delegation mechanism should allow for long-lived static
pre-assignment of prefixes and for automated, possibly short-lived,
on-demand, dynamic assignment of prefixes to a customer.
The offered prefix may be stable or change from time to time; it is generally expected that ISPs will offer relatively stable prefixes
to their residential customers. Regardless, the home network needs to be adaptable as far as possible to ISP prefix allocation
policies and assume nothing about the stability of the prefix received from an ISP or the length of the prefix that may be offered.
[...]
(ci-dessous, plus spécifique)
The norm for residential customers of large ISPs may be similar to their single IPv4 address provision; by default it is likely to
remain persistent for some time, but changes in the ISP's own provisioning systems may lead to the customer's IP (and in the
IPv6 case their prefix pool) changing. It is not expected that ISPs will generally support Provider Independent (PI) addressing
for residential homenets.
[...]
There may be cases where local law means some ISPs are required to change IPv6 prefixes (current IPv4 addresses) for
privacy reasons for their customers.
Source : https://www.rfc-editor.org/rfc/rfc7368#page-24
Dans le cas de l'auto-configuration IPv6 sans état (RFC 4862) (cf. Configuration automatique), le client de mise à jour dynamique du DNS
(nsupdate par exemple) peut s'exécuter sur l'équipement-même concerné par la mise à jour. Dans le cas de l'autoconfiguration avec état
(DHCP) (cf. Configuration avec état :DHCPv6), le client de mise à jour peut soit s'exécuter sur l'équipement concerné soit être couplé au
serveur DHCP.
Source : https://livre.g6.asso.fr/index.php/NommageBis#4.1._Propagation_et_mise_.C3.A0_jour_dynamique_du_DNS
Le service DynDNS permet d'attribuer un nom de domaine et d'hôte fixe, facile à mémoriser, à une adresse IP statique ou dynamique ou à une longue URL.
Utile, par exemple, si vous hébergez un site web ou un serveur FTP derrière votre Livebox pour le retrouver facilement (nom de type monserveur.dydns.org).
on devrait clairement avoir un "long-lived static pre-assignment of prefixes".Attention, dans les RFC tous les mots sont importants, notamment le "should" dans ce cas qui fait que ce n'est en aucun cas une obligation mais une recommandation.
Le script sur le routeur c'est quand même le plus simple, même en IPv6, vu que le routeur, lui, il sait quand le préfixe change. Pendant très longtemps j'ai utilisé un script perso sur mon Mikrotik qui construisait une adresse IPv6 complète à partir du préfixe reçu et d'un suffixe "fixe", le tout dans une table (1 ligne par enregistrement DNS à mettre à jour). Mes noms de domaines sont hébergés chez Cloudflare.
Maintenant je n'ai plus ce problème, j'ai un /48 IPv6 fixe (un tunnel L2TP chez Milkywan).
Même pas de stateless ? :o C'est problématique par contre.Je viens de regarder dans winbox et je confirme. Pas de stateless non plus (perso j'envoie les DNS en SLAAC aussi).
En parlant de DDNS, j'ai développé un outil pour faciliter la MAJ de plusieurs noms.
En gros : le script tourne sur une machine linux dans le réseau, et monitor constamment son propre prefix.
Quand le prefix change, ça va update tous les enregistrements AAAA avec ce préfix sur les registrars configurés (Cloudflare et Ionos supportés).
Plus besoin de faire tourner un client DDNS sur chaque device.
Si ça peut en aider quelques uns :)
==> https://github.com/Mathis-6/update-ddns
protocol=dyndns2
server=infomaniak.com
login=XXXXXXXXX
password='XXXXXXXXXXXXXXXXXXX'
usev4=ifv4
ifv4=vlan832
xxxxxx.xxxxxxxx.fr
Dynamic DNS services currently supported include:
1984.is
ChangeIP
CloudFlare
ClouDNS
DDNS.fm
DigitalOcean
dinahosting
Directnic
DonDominio
DNS Made Easy
DNSExit
dnsHome.de
Domeneshop
DslReports
Duck DNS
DynDNS.com
EasyDNS
Enom
Freedns
Freemyip
Gandi
GoDaddy
Hurricane Electric
Infomaniak
INWX
Loopia
Mythic Beasts
NameCheap
NearlyFreeSpeech.net
Njalla
Noip
nsupdate - see nsupdate(1) and ddns-confgen(8)
OVH
Porkbun
regfish.de
Sitelutions
Yandex
Zoneedit
Même pas de stateless ? :o C'est problématique par contre.
Encore le statefull, ça peut se comprendre, mais le stateless avec le DNS notamment, beaucoup de systèmes s'en servent, comme de pas si vieilles versions de windows... Pour des routeurs ciblant bien plus les pros que les particuliers, ça fait tâche.
@halesk2k :Il ne l'est pas, c'est LeVieux qui l'a dit dans un de ces post ici.
Il paraît que le préfixe IPv6 assigné par Orange sur une connexion fixe est stable. Mais on peut renouveler son préfixe via l'interface Orange de son compte client (vie privée).
Les standards RFC de l'IETF relatifs à IPv6 évoluent au fil du temps. D'ailleurs, le passage mentionné du RFC 3769 contredit clairement ton affirmation : un préfixe peut êtreNon, elle ne contredit pas.
stable ou alors changer fréquemment (possibly, short-lived). Voir le RFC 7368 « Homenet ».
Je ne suis pas certain que ce soit une bonne idée, à notre époque (en 2025), de laisser ses enfants « jouer » avec sa connexion à l'Internet. L'écart de niveau devient
à mon avis très important. À minima il faut comprendre ce que l'on fait, et pouvoir éventuellement (potentiellement) faire face aux risques (agir).
@helesk2k :
L'auto-hébergement est possible. Il faut renseigner les informations dans le fichier de zone DNS fourni par le registraire de nom de domaine.
La mise à jour dynamique peut être proposée comme option du service. On peut l'observer dans l'interface de la Livebox : Réseau > DynDNS.
Attention, dans les RFC tous les mots sont importants, notamment le "should" dans ce cas qui fait que ce n'est en aucun cas une obligation mais une recommandation.
Si toi et zoc parlez bien de limiter DHCPv6 à envoyer des options, ça fonctionne pourtant chez moi (NTP, DNS et domaine de recherche).Ok, ça me semblait pas évident en regardant les options de conf possible dans winbox, où j’étais persuadé que le pool d’IPv6 était obligatoire. Bref de toute façon je n’ai que du macOS et du Linux sur mon réseau, les 2 se satisfont très bien des DNS fournis par SLAAC.
@halesk2k :Je cite la 2ème phrase de ton lien :)
Cela fait un bout de temps que j'avais configuré mon serveur Web. Il n'empêche qu'on peut le faire en IPv6. (https://assistance.orange.fr/livebox-modem/toutes-les-livebox-et-modems/installer-et-utiliser/piloter-et-parametrer-votre-materiel/le-parametrage-avance-reseau-nat-pat-ip/dns/livebox-configurer-un-service-dns-dynamique_188820-730441)
Le préfixe Orange est plutôt stable dans les faits. Plusieurs contributeurs du forum peuvent le confirmer.1 an, comme l'IPv4.
Étonnant ! Franchement, il faut voir qui il y a en face. J'ai horreur des zombies, botnets, cellules malicieuses.Ouvrir un port vers une IPv6 de ton LAN, c'est ni plus, ni moins risqué que de forward un port en IPv4 derrière un NAT.
Il y a des choses qui forcent l'admiration mais il faut voir les risques encourus. Je préfère être naïf.
Apr 23 10:10:02 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 4
Apr 23 10:10:06 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 11
Apr 23 10:10:17 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 9
Apr 23 10:10:26 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 15
Apr 23 10:10:41 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 20
Apr 23 10:11:01 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 2
Apr 23 10:11:03 dhclient 65497 No DHCPOFFERS received.
Apr 23 10:11:03 dhclient 65497 Trying recorded lease 90.127.83.72
Apr 23 10:11:03 dhclient 42794 TIMEOUT
Apr 23 10:11:03 dhclient 43734 Starting add_new_address()
Apr 23 10:11:03 dhclient 44347 ifconfig igc3.832 inet 90.127.83.72 netmask 255.255.248.0 broadcast 90.127.87.255
Apr 23 10:11:03 dhclient 44927 New IP Address (igc3.832): 90.127.83.72
Apr 23 10:11:03 dhclient 45674 New Subnet Mask (igc3.832): 255.255.248.0
Apr 23 10:11:03 dhclient 46182 New Broadcast Address (igc3.832): 90.127.87.255
Apr 23 10:11:03 dhclient 46748 New Routers (igc3.832): 90.127.80.1
Apr 23 10:11:04 dhclient 47898 New Routers (igc3.832): 90.127.80.1
Apr 23 10:11:05 dhclient 49488 Deleting old routes
Apr 23 10:11:05 dhclient 65497 No working leases in persistent database - sleeping.
Apr 23 10:11:05 dhclient 50612 FAIL Apr 3 15:39:04 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 3 15:39:04 dhclient 63182 DHCPACK from 80.10.236.97
Apr 3 15:39:04 dhclient 63182 unknown dhcp option value 0x5a
Apr 3 15:39:04 dhclient 63182 unknown dhcp option value 0x7d
Apr 3 15:39:04 dhclient 99624 RENEW
Apr 3 15:39:04 dhclient 576 Creating resolv.conf
Apr 3 15:39:04 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 4 15:24:40 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 4 15:24:40 dhclient 63182 DHCPACK from 80.10.236.97
Apr 4 15:24:40 dhclient 63182 unknown dhcp option value 0x5a
Apr 4 15:24:40 dhclient 63182 unknown dhcp option value 0x7d
Apr 4 15:24:40 dhclient 97270 RENEW
Apr 4 15:24:40 dhclient 98364 Creating resolv.conf
Apr 4 15:24:40 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 5 15:10:16 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 5 15:10:17 dhclient 63182 DHCPACK from 80.10.236.97
Apr 5 15:10:17 dhclient 63182 unknown dhcp option value 0x5a
Apr 5 15:10:17 dhclient 63182 unknown dhcp option value 0x7d
Apr 5 15:10:17 dhclient 86199 RENEW
Apr 5 15:10:17 dhclient 86858 Creating resolv.conf
Apr 5 15:10:17 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 6 14:55:53 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 6 14:55:53 dhclient 63182 DHCPACK from 80.10.236.97
Apr 6 14:55:53 dhclient 63182 unknown dhcp option value 0x5a
Apr 6 14:55:53 dhclient 63182 unknown dhcp option value 0x7d
Apr 6 14:55:53 dhclient 94803 RENEW
Apr 6 14:55:53 dhclient 95739 Creating resolv.conf
Apr 6 14:55:53 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 7 14:41:29 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 7 14:41:29 dhclient 63182 DHCPACK from 80.10.236.97
Apr 7 14:41:29 dhclient 63182 unknown dhcp option value 0x5a
Apr 7 14:41:29 dhclient 63182 unknown dhcp option value 0x7d
Apr 7 14:41:29 dhclient 36860 RENEW
Apr 7 14:41:29 dhclient 37647 Creating resolv.conf
Apr 7 14:41:29 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 8 14:27:05 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 8 14:27:06 dhclient 63182 DHCPACK from 80.10.236.97
Apr 8 14:27:06 dhclient 63182 unknown dhcp option value 0x5a
Apr 8 14:27:06 dhclient 63182 unknown dhcp option value 0x7d
Apr 8 14:27:06 dhclient 13522 RENEW
Hello à toutes et tous,
...
Il y a eu un truc hier a 20h22 j'ai changé d'IP (v4 et v6) sans reboot de ma livebox 6 (Paris).Bonjour
L'IPv4 change en même temps que le préfixe IPv6 ou on peut avoir le changement de l'un et pas de l'autre ?DualStack : on change les deux en même temps.
Aurais-tu atteint la limite de temps de possession de l'ancienne IP ? Car il semble prévu de changer d'IP au moins une fois par an.
Bonjour
Dès que la config de la ligne change, il y a renouvellement des IPs. Cela se fait sans nécessairement reboot de la LB.
Et quand je dis modification de ligne, c'est "large" :
- débrassage rebrassage sur un autre OLT / BNG
- change de profil de ligne (rappel, y'a un rétrofit de tout le parc pour un upgrade de débit)
- changement d'une option commerciale.
Cela se fait au renew de l'un des stack en général, donc un peu n'importe quand.
LeVieux
Hello à toutes et tous,
est-ce qu'il y aurait eu des changements sur la partie DHCP avec Orange?
Tout marchait bien depuis des mois et depuis ce matin je n'arrive plus à avoir d'IP.
Je suis sur un ONT + routeur PFsense
J'ai rebranché la Livebox et elle ça fonctionne bien j'ai bien une IP.
J'ai ça dans les logs du PFsense :Code: [Sélectionner]Apr 23 10:10:02 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 4
Apr 23 10:10:06 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 11
Apr 23 10:10:17 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 9
Apr 23 10:10:26 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 15
Apr 23 10:10:41 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 20
Apr 23 10:11:01 dhclient 65497 DHCPDISCOVER on igc3.832 to 255.255.255.255 port 67 interval 2
Apr 23 10:11:03 dhclient 65497 No DHCPOFFERS received.
Apr 23 10:11:03 dhclient 65497 Trying recorded lease 90.127.83.72
Apr 23 10:11:03 dhclient 42794 TIMEOUT
Apr 23 10:11:03 dhclient 43734 Starting add_new_address()
Apr 23 10:11:03 dhclient 44347 ifconfig igc3.832 inet 90.127.83.72 netmask 255.255.248.0 broadcast 90.127.87.255
Apr 23 10:11:03 dhclient 44927 New IP Address (igc3.832): 90.127.83.72
Apr 23 10:11:03 dhclient 45674 New Subnet Mask (igc3.832): 255.255.248.0
Apr 23 10:11:03 dhclient 46182 New Broadcast Address (igc3.832): 90.127.87.255
Apr 23 10:11:03 dhclient 46748 New Routers (igc3.832): 90.127.80.1
Apr 23 10:11:04 dhclient 47898 New Routers (igc3.832): 90.127.80.1
Apr 23 10:11:05 dhclient 49488 Deleting old routes
Apr 23 10:11:05 dhclient 65497 No working leases in persistent database - sleeping.
Apr 23 10:11:05 dhclient 50612 FAIL
Quand ça marchait j'avais des logs de ce type, ll y avait des warning de dhcp option non connues 0x5a et 0x7d , mais ça n'avait pas l'air d'avoir d'impact :Code: [Sélectionner]Apr 3 15:39:04 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 3 15:39:04 dhclient 63182 DHCPACK from 80.10.236.97
Apr 3 15:39:04 dhclient 63182 unknown dhcp option value 0x5a
Apr 3 15:39:04 dhclient 63182 unknown dhcp option value 0x7d
Apr 3 15:39:04 dhclient 99624 RENEW
Apr 3 15:39:04 dhclient 576 Creating resolv.conf
Apr 3 15:39:04 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 4 15:24:40 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 4 15:24:40 dhclient 63182 DHCPACK from 80.10.236.97
Apr 4 15:24:40 dhclient 63182 unknown dhcp option value 0x5a
Apr 4 15:24:40 dhclient 63182 unknown dhcp option value 0x7d
Apr 4 15:24:40 dhclient 97270 RENEW
Apr 4 15:24:40 dhclient 98364 Creating resolv.conf
Apr 4 15:24:40 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 5 15:10:16 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 5 15:10:17 dhclient 63182 DHCPACK from 80.10.236.97
Apr 5 15:10:17 dhclient 63182 unknown dhcp option value 0x5a
Apr 5 15:10:17 dhclient 63182 unknown dhcp option value 0x7d
Apr 5 15:10:17 dhclient 86199 RENEW
Apr 5 15:10:17 dhclient 86858 Creating resolv.conf
Apr 5 15:10:17 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 6 14:55:53 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 6 14:55:53 dhclient 63182 DHCPACK from 80.10.236.97
Apr 6 14:55:53 dhclient 63182 unknown dhcp option value 0x5a
Apr 6 14:55:53 dhclient 63182 unknown dhcp option value 0x7d
Apr 6 14:55:53 dhclient 94803 RENEW
Apr 6 14:55:53 dhclient 95739 Creating resolv.conf
Apr 6 14:55:53 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 7 14:41:29 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 7 14:41:29 dhclient 63182 DHCPACK from 80.10.236.97
Apr 7 14:41:29 dhclient 63182 unknown dhcp option value 0x5a
Apr 7 14:41:29 dhclient 63182 unknown dhcp option value 0x7d
Apr 7 14:41:29 dhclient 36860 RENEW
Apr 7 14:41:29 dhclient 37647 Creating resolv.conf
Apr 7 14:41:29 dhclient 63182 bound to 90.127.83.72 -- renewal in 85536 seconds.
Apr 8 14:27:05 dhclient 63182 DHCPREQUEST on igc3.832 to 80.10.236.97 port 67
Apr 8 14:27:06 dhclient 63182 DHCPACK from 80.10.236.97
Apr 8 14:27:06 dhclient 63182 unknown dhcp option value 0x5a
Apr 8 14:27:06 dhclient 63182 unknown dhcp option value 0x7d
Apr 8 14:27:06 dhclient 13522 RENEW
Il me reste éventuellement à tester l'ONT devant la livebox pour vérifier si le problème vient de lui, mais sinon je n'ai pas trop d'idée,
ça parle à quelqu'un ? :(
Je met en PJ mes configuration de la partie DHCP dans l'interface PFSense
Merci d'avance !
pas sur les ICMP, ARP... ça pourrait venir de là ?C'est une possibilité.
Et pour info, comme pressenti, avec la Livebox, cela fonctionne directement de nouveau...Bonjour
=> durcissement COS6 ? Actuellement, si j'ai bien compris, elle s'applique sur les requêtes DHCP avec OPNsense, pas sur les ICMP, ARP... ça pourrait venir de là ?
Et si la LB en ta possession est prévue pour fonctionner avec un ONT externe ! Je ne sais pas du tout si c'est le cas des LB 6 et 7 (ça me surprendrait un peu vue la "promesse" de débit sur le plan commercial).Les LB 6/7 fonctionne avec un ONT externe.
Je pense que c'est un souci avec (cette merde, désolé fallait que je le dise) le client DHCP de BSD.pourtant les systèmes BSD ont fait leurs preuves depuis longtemps sur routeur/serveur, leur fiabilité n'est plus à démontrer.
Ca fait longtemps que je me suis barré des truc tourant sur BSD (pfsense, opnsense and co ...)
Bonjour,
Il faudrait capturer le trafic Ethernet depuis/vers l'arbre PON pour y voir plus clair.
Autre idée afin de trancher s'il s'agit d'un problème PON ou d'autre chose : connecter la LB derrière ce WAS-110.
Via un MC220L ou bien par l'intermédiaire de l'équipement accueillant actuellement l'ONT/U SFP, s'il dispose de ports cuivre et en le faisant fonctionner en mode "bridge" (sous réserve qu'il laisse intact le marquage CoS/DSCP de la LB).
Et si la LB en ta possession est prévue pour fonctionner avec un ONT externe ! Je ne sais pas du tout si c'est le cas des LB 6 et 7 (ça me surprendrait un peu vue la "promesse" de débit sur le plan commercial).
Ouch !
Ca devient un peu (trop) compliqué pour moi ;D
Sniffer, je comprends la théorie. Ensuite, il faut savoir comment s'y prendre dans ces cas particuliers, et savoir isoler ce qu'on cherche avant d'interpréter le contenu.
Je ne fais ça pour ainsi dire jamais...
Je n'ai aucun outil matériel spécifique... il me faudrait sniffer entre le routeur et le WAS-110 j'imagine (en espérant comme tu dis que rien ne soit transformé).
Je vais voir si je trouve le temps, l'outillage (et le courage...) pour me lancer.
Ca pourrait aussi être une régression de dhclient entre des versions d'OPNsense ? qui serait intervenue entre 2 renews requis ? (probabilité faible peut-être...)
Merci en tout cas pour vos retours.
J'avais commencé à étudier ton tuto complet (a la base, je suis plutôt Linux que BSD), et j'ai hésité.
Alors, oui, honnêtement, l'absence d'ihm a joué. Plus par crainte de ne pas savoir faire en ligne de commande, de ne pas avoir les connaissances suffisantes, de perdre les tableaux de bord, outils statistiques, plugins...
Comme j'aime expérimenter les fonctionnalités, mais que je suis pas un habitué de networkd et cie, l'absence d'ihm rend les choses plus longues et moins pratiques je trouve. L'apprentissage sera lassez ong.
En outre, je suis en multiwan, failover cellulaire. Je ne pense pas savoir comment faire cela avec Linux sans y consacrer des jours homme de travail.
Par ailleurs, j'ai configuré le décodeur TV, ce que j'aurai aussi du mal à faire je suppose (proxy IGMP).
Tout cela représenterait un défi sympa, mais j'ai besoin d'un truc assez rapidement opérationnel, et je n'ai pas suffisamment de temps à y consacrer pour aboutir dans un temps raisonnable.
Bref, je réfléchis et pèse le pour et le contre.
Merci pour ta suggesion.
Et la bonne nouvelle c'est que tu peux utiliser un autre HDD/SSD pour installer Debian et config le tout, tout en conservant BSD au cas ou ... dual boot.
Suite à plusieurs questions dans le forum, j'ai précisé l'algo préconisé pour le test de vie.
Celui fait par la LB en fait
Voir le message #2 de ce threadPréconisation d'algo pour les tests de vie :
- IPv4 : faire une séquence ARP Request / Reply vers l'adresse du routeur donné en DHCPv4
- IPv6 : faire une séquence ICMP6 NS/NA de fe80::ba0:bab
- Pour chacun des deux stack
- faire une séquence toutes les 120s
- en cas de non réponse au bout de 10s , faire 2 répétitions
- au 3ème timeout (donc au total 150s de timeout), considérer que la liaison est en échec
- relancer CE stack
- les req ARP et ICMPv6 doivent être faite avec la COS6
LeVieux
1 an, comme l'IPv4.Je confirme : chez moi le préfixe a changé au bout d'1 an, d'ailleurs le suivant est pour bientôt.
Tu vas vite te rendre compte que IPv6 est formidable et que le monde n'est vraiment pas prêt.
Hello,
Bon, j'ai refait des tests ce jour, et j'ai réussi à refaire fonctionner le bouzin, mais je n'ai pas (encore ?) compris le souci de fonds.
Je ne comprenais pas pourquoi je ne voyais pas les requêtes dhcp sur les logs firewall.
Du coup, je me suis mis à faire du tcpdump sur la VM OPNsense.
Et, là, miracle, je voyais du trafic, plein de trafic, pas uniquement du dhcp.
Et je voyais mon IP publique apparaitre à chaque ligne ou presque !
Ne comprenant pas, je suis allé voir la vue Overview des interfaces, et les IPv4 et v6 étaient apparues comme par miracle.
Et, lorsque j'arrêtais tcpdump, je perdais la connectivité ?!
Après quelques recherches, je suis tombé là-dessus : https://forum.netgate.com/topic/67876/can-t-connect-to-lan-interface-unless-tcpdump-is-running
où quelqu'un mentionne que tcpdump fait passer l'interface en mode '"promiscuous".
J'ai donc tenté d'activer le mode sur l'interface, et ça fonctionne.
J'imagine que ce n'est pas "normal" (et je ne sais pas s'il est souhaitable de conserver ce mode)... Qu'est-ce qui expliquerait qu'il me faut désormais activer ce mode pour que cela fonctionne ?
En tout cas, merci pour vos conseils.
Je suis allé vérifier et les ONT software version 0 et 1 avaient changé par rapport à ma configuration d'origine. Donc j'ai calqué les versions de ma livebox dans mon ONT, et hop tout a refonctionné direct.
Orange a l'air de vérifier les version de maj de l'ONT de la Livebox avant de bien vouloir fournir un accès maintenant !
Non
Tu avais un ONT en O5.1 (sinon tu n'aurais pas eu de réponse au DHCP puisque tu as obtenu un 172.xx.xx.xx). Une fois l'ONT en O5.1 tu as un lien physique ONT<->OLT et ensuite c'est le lien IP qui prend le relais.
Tu n'avais pas d'IP car tu as probablement cramer toutes tes lease DHCP sans les rendre (release) et tu as du attendre une semaine avant de pouvoir faire une nouvelle demande (qui à fonctionné car timeout de tes précédentes lease).
Je répète donc :
- Orange s'en cogne des soft version, il n'y a que 3 param de vraiment important (serial, hardware version, vendor version)
- Tu avais une mauvaise config DHCP + COS6 + MAC addr et tu as cramer l'ensemble de tes lease DHCP
Par contre je pense que tu as raison, c'est p-e plus la partie Hardware Version qui a joué car j'étais en HW_HWVER LEOX avant de calquer celui de ma Livebox SMBSSGLB6110 , mais bon ça fonctionnait sans depuis ~ 1 an.A priori seuls les OLT Nokia (ALCL) vérifient Hardware Version, ceux de Huawei (HWTC) n'ont pas besoin du paramètre.
...
il n'y a que 3 param de vraiment important (serial, hardware version, vendor version)
A priori seuls les OLT Nokia (ALCL) vérifient Hardware Version, ceux de Huawei (HWTC) n'ont pas besoin du paramètre.
Donc soit :
- tu étais sur un OLT ALCL qui ne faisait pas la vérification, et sa configuration a été corrigée
- des OLT HWTC vérifient maintenant Hardware Version
- ton OLT a été changé (pour le déploiement du XGS-PON ?) de HWTC à ALCL
Tu peux regarder quel type d'OLT tu as actuellement avec "omcicli mib get 131".
Pour l'option 61 il s'agit de l'adresse mac de la LB.Et quelle est l'adresse mac de l'interface physique ?
Et quelle est l'adresse mac de l'interface physique ?
10:35:46.291314 IP (tos 0xc0, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 420)
0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 58:1d:d8:xx:xx:xx (oui Unknown), length 392, xid 0xe8d34f47, Flags [none] (0x0000)
Client-Ethernet-Address 58:1d:d8:xx:xx:xx (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
BR (28), Lease-Time (51), RN (58), RB (59)
AUTH (90), Unknown (119), Unknown (120), Unknown (125)
AUTH (90), length 70: x.x.x.x.x.x.x.x.x.x.x.xx.x.x.x.x.xx.x.x.xx.x.xx.xxx.xxx.xxx.xx.xx.xxx.xxx.xxx.xxx.xx.xx.xx.xx.xx.xx.xx.xxx.xx.xx.xx.xx.xx.xx.xx.xx.xx.xx.xx.xx.x.xx.xx.xxx.xx.xxx.xxx.xxx.xx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xx.xxx
Vendor-Class (60), length 5: "sagem"
Client-ID (61), length 7: ether 58:1d:d8:xx:xx:xx
User-Class (77), length 44:
instance#1: "FSVDSL_livebox.Internet.softathome.Livebox7", length 43
END (255), length 0
3: wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 64:9d:99:yy:yy:yy brd ff:ff:ff:ff:ff:ff
altname enp0s16f0
inet 192.168.100.3/24 brd 192.168.100.255 scope global wan
valid_lft forever preferred_lft forever
inet6 fe80::669d:99ff:feb2:517a/64 scope link
valid_lft forever preferred_lft forever
7: vlan832@wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 58:1d:d8:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 169.254.8.254/16 brd 169.254.255.255 scope link vlan832:avahi
valid_lft forever preferred_lft forever
inet6 fe80::5a1d:d8ff:fe9d:4330/64 scope link
valid_lft forever preferred_lft forever
Parce qu'en fait on s'en fout de la mac de la LB (moi j'ai une mac d'EdgeRouter dans mon option 61). Par contre la mac dans l'option 61 doit obligatoirement être la même que la mac de l'interface WAN.Je confirme : choisir une MAC et la mettre partout proprement. C'est pas obligatoirement celle de la LB.
Et manifestement l'ONU est fonctionnel vu que le "parquage" fonctionne.Je confirme : si tu as une réponse, même de parcage, c'est que la liaison fibre est opérationnelle
Je confirme : si tu as une réponse, même de parcage, c'est que la liaison fibre est opérationnellec'est aussi ce que je me disais, mais ne connaissant pas spécialement le fonctionnement des liaisons FTTH j'ai préféré en douter...
T'as pas fait trop de tentatives ce qui fait qu'il faut que tu attendes l'expiration de ces leases.? (c'est une idée juste)Utilisant la même adresses mac que la LB, techniquement je devrais obtenir la même lease non ?
peut-être un mécanisme de DHCPv4 Over DHCPv6 (RFC 7341) est utilisé désormais ?Non. Les box ont toujours affiché "DHCPv6" depuis qu'IPv6 est dispo.
@ybayart:C'est bien déjà le cas, mais comme en dhcpv4 je n'ai aucun retour sauf en provoquant volontairement une erreur de cos.
Non, il faut également que l'IAID soit identique. Une liaison DHCPv6 est définie par le tuple <DUID, IA-type, IAID> (https://www.rfc-editor.org/rfc/rfc8415.html#section-4.2).
La Livebox utilise les 8 derniers chiffres hexadécimaux de son adresse MAC comme IAID.
brctl addbr br0
brctl addif br0 ens16f2 ens16f3
ip link set up ens16f2 <- depuis la LB
ip link set up ens16f3 <- vers le PTO
ip link set up br0
Si le bridge laisse bien passer le COS tel quel, alors effectivement ça devrait normalement fonctionner.Sur un wireshark de l'interface du stick je vois bien le paquet avec la prio et le vlan donc oui tout est conservé.
Peut-être qu'il y a des règles VLAN particulières qui ne fonctionneraient pas, sachant qu'un ONT peut modifier le COS.
https://akhamar.github.io/orange-xgs-pon/20_fs_onu/22_verif.html : ici la règle pour le VLAN 832 est de le transformer en 2800 tout en reprenant la priorité, je ne sais pas si elle vient d'un OLT HTWC ou ALCL.
Que donnent "/system/mib/show 506" (et éventuellement "/system/mib/show 171"), et "/traffic/eth/show connect all" ?
/system/mib/show 506
Table RxFrmOpTbl, Received frame VLAN Tagging Operation Tabl, total 8 instances
EntityID = 0x0001
OuterPriFilter = 14
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 14
InnerVidFilter = 4096
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 3
OuterPriTreat = 15
OuterVidTreat = 0
OuterTPIDTreat = 0
InnerPriTreat = 15
InnerVidTreat = 0
InnerTPIDTreat = 0
EntityID = 0x0001
OuterPriFilter = 15
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 5
InnerVidFilter = 840
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 1
OuterPriTreat = 15
OuterVidTreat = 0
OuterTPIDTreat = 0
InnerPriTreat = 4
InnerVidTreat = 840
InnerTPIDTreat = 0
EntityID = 0x0001
OuterPriFilter = 15
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 6
InnerVidFilter = 851
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 1
OuterPriTreat = 15
OuterVidTreat = 0
OuterTPIDTreat = 0
InnerPriTreat = 5
InnerVidTreat = 852
InnerTPIDTreat = 0
EntityID = 0x0001
OuterPriFilter = 15
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 8
InnerVidFilter = 832
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 1
OuterPriTreat = 15
OuterVidTreat = 0
OuterTPIDTreat = 0
InnerPriTreat = 8
InnerVidTreat = 2800
InnerTPIDTreat = 0
EntityID = 0x0001
OuterPriFilter = 15
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 8
InnerVidFilter = 835
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 1
OuterPriTreat = 15
OuterVidTreat = 0
OuterTPIDTreat = 0
InnerPriTreat = 8
InnerVidTreat = 835
InnerTPIDTreat = 0
EntityID = 0x0001
OuterPriFilter = 15
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 8
InnerVidFilter = 838
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 1
OuterPriTreat = 15
OuterVidTreat = 0
OuterTPIDTreat = 0
InnerPriTreat = 8
InnerVidTreat = 838
InnerTPIDTreat = 0
EntityID = 0x0001
OuterPriFilter = 15
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 14
InnerVidFilter = 4096
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 3
OuterPriTreat = 15
OuterVidTreat = 0
OuterTPIDTreat = 0
InnerPriTreat = 15
InnerVidTreat = 0
InnerTPIDTreat = 0
EntityID = 0x0001
OuterPriFilter = 15
OuterVidFilter = 4096
OuterTPIDFilter = 0
InnerPriFilter = 15
InnerVidFilter = 4096
InnerTPIDFilter = 0
EtherTypeFilter = 0
AniBriPortNum = 0
RmTagTreat = 0
OuterPriTreat = 15
OuterVidTreat = 4096
OuterTPIDTreat = 0
InnerPriTreat = 1
InnerVidTreat = 1
InnerTPIDTreat = 4
/system/mib/show 171
Table ExtVlanTagOp, Extended VLAN Tagging Operation Configuration Data, total 1 instances
EntityID = 0x0001
Type = 2
MaxSizeOfOpTbl = 17
InputTPID = 0x8100
OutputTPID = 0x8100
DsMode = 0
RxFrmOpTbl =
Pointer = 0x0101
DscpMap2Pbit = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
/traffic/eth/show connect all
$$ US BRIDGE 65535 $$
---------------------------------------------------------------
< INDEX = 0, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x1>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 0
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 1, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x1>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 0
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 2, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x2>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 1
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 1
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 3, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x4>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 2
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 1
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 4, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x2>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 1
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 1
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 5, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x4>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 2
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 1
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 6, SLOT = 1, PORT = 4, VLANFILTER = 61440 PRIFILTER = 0xff>
VLAN MATCH : UNTAGGED
VLAN ACT : ADD_AND_REMARK
OUT VID : 1
OUT PRI : 1
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 1
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 7, SLOT = 1, PORT = 4, VLANFILTER = 840 PRIFILTER = 0x20>
VLAN MATCH : MATCH
VLAN ACT : REPLACE_AND_REMARK
OUT VID : 840
OUT PRI : 4
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 2
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 8, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x8>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 3
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 2
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 9, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x10>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 4
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 2
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 10, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x40>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 6
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 2
* PRI 7 -> FLOW 0
< INDEX = 11, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x80>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 7
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 2
< INDEX = 12, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x8>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 3
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 2
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 13, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x10>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 4
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 2
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 14, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x40>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 6
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 2
* PRI 7 -> FLOW 0
< INDEX = 15, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x80>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 7
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 0
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 2
< INDEX = 16, SLOT = 1, PORT = 4, VLANFILTER = 851 PRIFILTER = 0x40>
VLAN MATCH : MATCH
VLAN ACT : REPLACE_AND_REMARK
OUT VID : 852
OUT PRI : 5
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 3
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 17, SLOT = 1, PORT = 4, VLANFILTER = 832 PRIFILTER = 0x20>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 2800
OUT PRI : 5
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 3
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
< INDEX = 18, SLOT = 1, PORT = 4, VLANFILTER = 835 PRIFILTER = 0x20>
VLAN MATCH : MATCH
VLAN ACT : REPLACE
OUT VID : 835
OUT PRI : 5
TCI MAPPING:
* PRI 0 -> FLOW 0
* PRI 1 -> FLOW 0
* PRI 2 -> FLOW 0
* PRI 3 -> FLOW 0
* PRI 4 -> FLOW 0
* PRI 5 -> FLOW 3
* PRI 6 -> FLOW 0
* PRI 7 -> FLOW 0
$$ DS BRIDGE 65535 $$
---------------------------------------------------------------
< INDEX = 0, GEM FLOW = 30, VID = 65535, PRI = 255, GEM TYPE = MCAST>
VLAN ACT : (0)ASIS
OLD VID : 65535
OLD PRI : 8
OUTER VID : 0
OUTER PRI : 0
++UNI[0] slot = 1 port = 1
< INDEX = 1, GEM FLOW = 0, VID = 2800, PRI = 255, GEM TYPE = UCAST>
VLAN ACT : (3)REPLACE
OLD VID : 2800
OLD PRI : 8
OUTER VID : 832
OUTER PRI : 8
++UNI[0] slot = 1 port = 1
< INDEX = 2, GEM FLOW = 0, VID = 835, PRI = 255, GEM TYPE = UCAST>
VLAN ACT : (3)REPLACE
OLD VID : 835
OLD PRI : 8
OUTER VID : 835
OUTER PRI : 8
++UNI[0] slot = 1 port = 1
< INDEX = 3, GEM FLOW = 1, VID = 1, PRI = 255, GEM TYPE = UCAST>
VLAN ACT : (8)REMOVE
OLD VID : 1
OLD PRI : 8
OUTER VID : 61440
OUTER PRI : 8
++UNI[0] slot = 1 port = 1
< INDEX = 4, GEM FLOW = 2, VID = 840, PRI = 16, GEM TYPE = UCAST>
VLAN ACT : (4)REPLACE_AND_REMARK
OLD VID : 840
OLD PRI : 4
OUTER VID : 840
OUTER PRI : 5
++UNI[0] slot = 1 port = 1
< INDEX = 5, GEM FLOW = 3, VID = 852, PRI = 32, GEM TYPE = UCAST>
VLAN ACT : (4)REPLACE_AND_REMARK
OLD VID : 852
OLD PRI : 5
OUTER VID : 851
OUTER PRI : 6
++UNI[0] slot = 1 port = 1
Ton ONT est en O5.x et tu obtiens des IP de parking (172.X.X.X). Oublie l'ONT il est OK, c'est ta config DHCP qui est mal faite. Plus tu passera de temps sur l'ONT plus tu perdras de temps.Moi mon ONT est O5.1 même sans configurer mon S/N ni mon HW Version. J’ai essayé de mettre un faux S/N ça marche aussi. Je sais pas si c’est un cas isolé à mon OLT mais c’est très très bizarre.
@ybayart suis ça : https://akhamar.github.io/orange-bypass-debian/
Tu en as pour 30min de copier/coller. Si tu obtiens une IPv4 tu sais alors que ta config DHCP est merdique.
Ton ONT est en O5.x et tu obtiens des IP de parking (172.X.X.X). Oublie l'ONT il est OK, c'est ta config DHCP qui est mal faite. Plus tu passera de temps sur l'ONT plus tu perdras de temps.
Pour info, si tu utilises une VM, il est possible que ça soit la cause. Sur la VM ça indiquera cos6 mais sur la physique les trames seront envoyé en 0.
- VLAN 832 => VLAN 2800 (en conservant la priorité)si je comprends bien, l'ONT transforme le vlan 832 vers le 2800 pour l'OLT ?
si je comprends bien, l'ONT transforme le vlan 832 vers le 2800 pour l'OLT ?Oui, c'est une configuration sur certains OLT GPON (dont une partie n'avaient pas le mapping initialement), et peut-être tous les OLT XGS-PON.
si je comprends bien, l'ONT transforme le vlan 832 vers le 2800 pour l'OLT ?Bonjour
Je suis passé voir mon expert :En 2021, avec un OLT Nokia en GPON, la translation était faite côté ONT : https://lafibre.info/remplacer-livebox/guide-de-connexion-fibre-directement-sur-un-routeur-voire-meme-en-2gbps/msg894865/#msg894865.
- sur OLT HUAWEI + XGS : la translation 832 vers 2800 est faite coté ONT
- sur OLT NOKIA + XGS : la translation 832 vers 2800 est faite coté OLT (donc PAS dans l'ONT)
- si l'ONU est bien compatible OMCI, c'est poussé de manière transparente par l'OLT (donc rien à faire en dur dans l'ONT
Je ne sais pas comment vous pouvez savoir si vous être face à un OLT de l'un ou l'autre des constructeurs (mes outils internes, ben ils sont internes ...)
Pour les OLT Huawei en GPON, il y en a qui poussent toujours une config 832 => 832, et d'autres qui ont changé et demandent 832 => 2800.Non, là c'est plus une optimisation de fonctionnement d'un constructeur. Au cout de ramener une partie de ce que l'on aurait préféré (question de design) garder dans l'OLT dans l'ONU.
Donc soit certains OLT Huawei font la translation, soit il y a des parties du backbone qui sont toujours en 832 (sans différenciation GP / PRO ?).