Bonjour,

Ton analyse est déjà très propre et, à mon avis, tu as suffisamment avancé pour écarter un simple problème de VLAN ou de clonage de MAC.

Il faut cependant bien séparer deux couches qui sont souvent mélangées dans ce type de remplacement :

• La couche optique/PON : ONU, enregistrement auprès de l’OLT, OMCI, GEM ports et translation des VLAN.
  
• La couche IP opérateur : IPv6 WAN, IPv4, routage, tunnel éventuel, provisioning et mécanismes spécifiques à la Freebox Pro.
  

Dans ta situation actuelle, le boîtier ONU Free est déjà synchronisé et transmet bien du trafic Ethernet à l’UDM. Ton blocage se situe donc principalement dans la seconde couche.

1. Ce que tes captures permettent déjà d’affirmer

Le fait que l’UDM reçoive des Router Advertisement sur le VLAN 836 démontre que :

• l’ONU est opérationnel ;
• le chemin optique est établi ;
• le VLAN 836 arrive correctement jusqu’à l’UDM ;
• le clonage de MAC n’est pas totalement rejeté par l’infrastructure ;
• le voisin IPv6 amont est au moins joignable au niveau Ethernet/ICMPv6.

En revanche, les champs suivants du Router Advertisement :

Managed Address Configuration : 0
Other Configuration           : 0

ne signifient pas que l’UDM doit automatiquement recevoir une IPv6 globale.

Ils indiquent seulement que le routeur amont ne demande pas d’utiliser DHCPv6 pour fournir l’adresse ou d’autres paramètres.

Pour savoir si SLAAC est réellement possible, il faut ouvrir complètement le paquet RA et regarder la présence d’une option :

ICMPv6 Prefix Information

et notamment :

Autonomous address-configuration flag : 1
Prefix length                         : généralement /64
Valid lifetime                        : non nul
Preferred lifetime                    : non nul

Si le RA ne contient aucun Prefix Information Option, ou si le flag Autonomous vaut 0, l’UDM ne peut pas fabriquer d’adresse IPv6 globale par SLAAC.

Le RA peut alors uniquement servir à fournir :

• une route par défaut ;
• l’adresse link-local du routeur amont ;
• une MTU ;
• des DNS via RDNSS ;
• éventuellement des routes supplémentaires.

Une adresse link-local et une route par défaut ne suffisent pas nécessairement à construire la connectivité attendue par Free Pro.

2. Le VLAN 301 ne fournit probablement pas une IPv4 par DHCP classique

Le fait de voir des paquets destinés à ton IPv4 publique sur le VLAN 301 est très intéressant, mais ne permet pas encore de conclure que le VLAN 301 fonctionne comme un WAN DHCPv4 classique.

Il faut vérifier précisément comment ces paquets sont transportés.

Dans Wireshark, regarde si le paquet visible sur le VLAN 301 est :

• un véritable paquet Ethernet IPv4 avec un EtherType 0x0800 ;
• ou un paquet IPv4 encapsulé dans IPv6, avec un champ IPv6 Next Header égal à 4.

Dans le deuxième cas, il s’agit d’IP-in-IP, c’est-à-dire d’IPv4 transportée dans IPv6.

Attention également à ne pas appeler automatiquement cela MAP-E ou 4rd. Le simple fait de voir du protocole IP numéro 4 démontre une encapsulation IPv4 dans IPv6, mais pas nécessairement l’utilisation complète de MAP-E ou de 4rd.

S’il s’agit au contraire de véritables trames IPv4 directement présentes sur le VLAN 301, il faudra examiner :

• l’adresse MAC source et destination ;
• la présence ou non d’ARP ;
• la passerelle utilisée ;
• le masque associé à l’IPv4 publique ;
• la présence éventuelle d’une route host /32 ;
• les éventuels DHCP Discover émis par la Freebox ;
• les options DHCP transmises par la Freebox.

Une IPv4 publique peut parfaitement être provisionnée statiquement dans la Freebox sans qu’aucun DHCP Offer ne soit visible au démarrage normal.

3. Le point essentiel : faire une capture depuis un démarrage totalement à froid

Une capture réalisée sur une Freebox déjà provisionnée peut manquer l’étape la plus importante.

La Freebox peut conserver dans sa configuration persistante :

• son préfixe IPv6 ;
• son IPv6 WAN ;
• son IPv4 publique ;
• l’adresse de la passerelle ;
• les paramètres du tunnel IPv4 ;
• un identifiant de session ;
• des informations téléchargées depuis les serveurs de configuration Free Pro.

Je referais donc une capture en démarrant l’enregistrement avant la mise sous tension de l’ONU et de la Freebox Pro.

L’ordre serait :


1. ONU et Freebox éteints
2. Démarrage de la capture sur le port miroir
3. Mise sous tension de l’ONU
4. Attente de sa synchronisation
5. Mise sous tension de la Freebox Pro
6. Capture pendant au moins 10 à 15 minutes
   
Il faut capturer sans filtre, puis filtrer après coup.

Filtres Wireshark intéressants :

vlan
arp
bootp
dhcpv6
icmpv6
pppoed || pppoes
ip.proto == 4
ipv6.nxt == 4
dns
tls.handshake.extensions_server_name

Et pour isoler les VLAN :

vlan.id == 301
vlan.id == 836
vlan.id == 302
vlan.id == 303
vlan.id == 4001

Des analyses historiques de Freebox Pro avaient également identifié des communications vers des services du type :

cfg.freepro.com
fmw.freepro.com
tlm.freepro.com

Il serait intéressant de vérifier si ces destinations existent toujours sur ta nouvelle offre et, surtout, ce qui se passe juste avant et juste après ces connexions.

Même si les échanges applicatifs sont chiffrés, la chronologie DNS/TLS peut révéler que la Freebox télécharge sa configuration IP après avoir obtenu une connectivité IPv6 minimale.

4. Hypothèse raisonnable sur les VLAN 836 et 301

À ce stade, je considérerais l’architecture suivante comme une hypothèse de travail, et non comme une certitude :

VLAN 836
IPv6 de transport ou de contrôle
Router Advertisement
Routeur amont accessible en link-local
Éventuelle IPv6 WAN configurée ou dérivée
Éventuel accès au provisioning Free Pro

VLAN 301
Service IPv4
IPv4 publique routée ou encapsulée
Paramètres éventuellement récupérés par la Freebox

Il est également possible que la Freebox utilise réellement deux interfaces WAN internes :

• une interface IPv6 sur le VLAN 836 ;
• une interface IPv4 ou un tunnel sur le VLAN 301.

Mais il faut le confirmer par la capture.

Les anciennes analyses Free Pro plaçaient plutôt le service principal sur le VLAN 301 avec une IPv4 transportée dans IPv6 et un préfixe IPv6 routé. Ton observation actuelle peut donc correspondre :

• à une évolution de l’architecture Free Pro ;
• à une différence liée à l’offre XGS-PON 7 Gbit/s ;
• à une translation réalisée par l’ONU ;
• à une séparation plus récente entre les interfaces de service ;
• ou simplement à une interprétation incomplète des paquets capturés.

Il ne faut donc pas appliquer directement les recettes destinées aux Freebox grand public ou aux anciens accès Free 10G-EPON.

Free Pro n’utilise pas nécessairement exactement la même collecte ni le même provisioning qu’une offre Free résidentielle.

5. Pourquoi les options de l’UDM ne donnent rien

Les options UniFi :

• DS-Lite ;
• MAP-E ;
• IPv4 over IPv6 ;
• SLAAC ;
• DHCPv6 ;
• Prefix Delegation ;

ne sont pas des mécanismes universels capables de détecter automatiquement n’importe quelle architecture opérateur.

Par exemple :

• DS-Lite nécessite une IPv6 WAN fonctionnelle et une adresse AFTR ;
• MAP-E nécessite des règles de mapping compatibles avec l’implémentation supportée par UniFi ;
• SLAAC nécessite un préfixe annoncé avec le flag Autonomous ;
• Prefix Delegation nécessite normalement un échange DHCPv6-PD ;
• un tunnel IPIP spécifique nécessite une IPv6 source, une IPv6 de destination et des routes explicitement définies.

UniFi sait aujourd’hui gérer certains cas d’IPv4 sur IPv6, mais cela ne signifie pas que l’UDM sait reproduire un mécanisme Free Pro propriétaire ou semi-propriétaire.

En particulier, l’interface UniFi n’est pas conçue pour créer librement :

• plusieurs sous-interfaces WAN indépendantes sur un même port ;
• un tunnel IPIP IPv4 dans IPv6 entièrement personnalisé ;
• une IPv6 WAN statique avec une passerelle link-local spécifique ;
• des règles de routage avancées entre plusieurs VLAN opérateur ;
• une IPv4 publique /32 routée par un tunnel personnalisé ;
• un mécanisme de provisioning propre à la Freebox.

Il est donc tout à fait possible que le remplacement soit techniquement réalisable avec Linux, VyOS ou MikroTik, mais pas directement depuis l’interface de l’UDM Pro Max.

6. Le clonage de MAC peut être nécessaire sans être suffisant

Tu as bien confirmé que les Router Solicitation utilisent la MAC clonée. C’est un bon point.

Mais la Freebox peut également utiliser :

• une IPv6 construite à partir de sa MAC ;
• une IPv6 configurée statiquement ;
• un DUID propre pour DHCPv6, même si aucun échange n’est visible actuellement ;
• un identifiant transmis lors du provisioning ;
• une adresse source précise attendue par le routeur amont ;
• une session entretenue périodiquement ;
• un Neighbor Advertisement particulier ;
• une configuration persistante déjà récupérée précédemment.

Il faut également comparer l’adresse IPv6 link-local utilisée par la Freebox et celle générée par l’UDM.

Cloner l’adresse MAC Ethernet ne garantit pas toujours que le routeur tiers utilisera exactement la même adresse link-local IPv6, notamment selon l’utilisation d’EUI-64, d’adresses stables ou d’un identifiant généré par le système.

7. Le meilleur chemin de résolution : conserver d’abord l’ONU Free

Je te conseille vraiment de découper le projet en deux étapes.

Étape 1 : remplacer uniquement la Freebox Pro

Topologie :

Fibre
|
ONU Free
|
Routeur Linux / VyOS / MikroTik
|
UDM Pro Max

L’équipement intermédiaire servirait à :

• terminer les VLAN 301 et 836 ;
• reproduire l’adressage IPv6 de la Freebox ;
• créer l’éventuel tunnel IPv4 dans IPv6 ;
• gérer les routes spécifiques ;
• présenter ensuite une connexion plus classique à l’UDM.

Un Linux avec deux interfaces 10 Gbit/s, ou une machine avec une interface SFP+ et une interface Ethernet 10G, serait probablement le meilleur outil de laboratoire.

Cela permettrait de tester librement :

• les VLAN ;
• les adresses IPv6 statiques ;
• les routes via une passerelle link-local ;
• IPIP ;
• le proxy NDP ;
• les MTU ;
• les tables de routage multiples.

Une fois la connexion fonctionnelle sous Linux ou VyOS, il sera possible de déterminer si la configuration peut être adaptée à MikroTik ou directement à UniFi.

Étape 2 : remplacer éventuellement l’ONU Free

Ce n’est qu’une fois la couche IP parfaitement comprise que je tenterais le remplacement de l’ONU par un WAS-110.

8. Ce qu’apporterait réellement un WAS-110

Le WAS-110 peut remplacer la fonction optique XGS-PON de l’ONU externe, à condition de reproduire correctement l’identité attendue par l’OLT :

• Vendor ID ;
• numéro de série PON ;
• Equipment ID ;
• version matérielle ;
• versions logicielles active et passive ;
• PLOAM password si utilisé ;
• LOID si utilisé ;
• paramètres OMCI ;
• mapping des GEM ports et des VLAN.

L’objectif serait d’obtenir un état :

O5 / O5.1

puis de vérifier dans les tables OMCI que les VLAN et les services sont correctement créés.

Mais le WAS-110 ne remplace que l’ONU.

Il ne reproduira pas automatiquement :

• le provisioning IP de la Freebox ;
• les deux éventuelles interfaces WAN ;
• le tunnel IPv4 dans IPv6 ;
• la récupération du préfixe ;
• la configuration téléchargée depuis Free Pro ;
• la logique de routage de la Freebox.

Mon propre retour d’expérience avec un WAS-110 sur une ligne SFR XGS-PON m’a appris un point important : obtenir O5/O5.1 et être correctement reconnu par l’OLT ne garantit absolument pas que le service IP fonctionnera.

Sur une ligne PON, il y a au minimum deux validations indépendantes :

Enregistrement PON réussi
!=
Service IP opérationnel

On peut être parfaitement enregistré auprès de l’OLT, recevoir les ordres OMCI et voir les VLAN, tout en n’obtenant aucun DHCP ou aucune connectivité IP parce que l’identité du CPE, le provisioning ou les paramètres de service ne sont pas encore reproduits.

Dans ton cas, remplacer immédiatement l’ONU Free par un WAS-110 ajouterait donc une seconde inconnue alors que le mécanisme IP Free Pro n’est pas encore identifié.

9. Test Linux minimal que je réaliserais

Avec l’ONU Free toujours en place, je brancherais temporairement une machine Linux directement derrière lui.

Exemple de création des VLAN :

ip link set dev enp1s0 address dc:XX:XX:XX:XX:00
ip link set dev enp1s0 up

ip link add link enp1s0 name enp1s0.301 type vlan id 301
ip link add link enp1s0 name enp1s0.836 type vlan id 836

ip link set dev enp1s0.301 up
ip link set dev enp1s0.836 up

Capture complète :

tcpdump -eni enp1s0 -s0 -w freepro-test.pcap

Affichage des Router Advertisement :

rdisc6 enp1s0.836

Affichage des voisins et routes :

ip -6 neigh show dev enp1s0.836
ip -6 route show
ip -6 address show dev enp1s0.836

DHCPv4 en mode très verbeux sur le VLAN 301 :

dhclient -4 -v enp1s0.301

DHCPv6, uniquement pour confirmer définitivement son absence :

dhclient -6 -v enp1s0.836

Il faudra évidemment éviter de lancer simultanément la Freebox et la machine de test avec la même MAC.

Ce test permettra de savoir si le blocage vient réellement du réseau Free Pro ou simplement du comportement limité de la pile WAN UniFi.

10. Les informations les plus utiles à publier maintenant

Pour poursuivre proprement l’analyse, il faudrait idéalement fournir :

• le détail complet du Router Advertisement reçu sur le VLAN 836 ;
• les Prefix Information Options éventuelles ;
• la valeur Router Lifetime ;
• la MTU annoncée ;
• les éventuelles Route Information Options ;
• la MAC et l’IPv6 link-local du routeur amont ;
• un exemple complet d’un paquet IPv4 vu sur le VLAN 301 ;
• la confirmation qu’il s’agit d’IPv4 natif ou d’IPv4 encapsulé ;
• les paquets ARP présents sur le VLAN 301 ;
• les éventuels DHCP Discover émis par la Freebox ;
• les options contenues dans ces DHCP Discover ;
• la chronologie complète du démarrage à froid ;
• la liste de tous les VLAN réellement observés ;
• la différence entre une capture Freebox connectée et une capture UDM connecté.

En masquant les adresses publiques et les identifiants sensibles, un extrait PCAP contenant uniquement le démarrage WAN serait beaucoup plus parlant que des captures d’écran.

Conclusion

À mon avis :

• le boîtier ONU Free n’est pas actuellement le problème ;
• le VLAN 836 fournit au minimum une connectivité IPv6 locale et une route amont ;
• les flags M=0/O=0 ne prouvent pas qu’une adresse SLAAC doit être attribuée ;
• le VLAN 301 transporte bien le service IPv4, mais son mécanisme d’activation reste à déterminer ;
• la Freebox récupère ou possède probablement des paramètres supplémentaires que l’UDM ne connaît pas ;
• le clonage de MAC est nécessaire, mais probablement insuffisant ;
• l’UDM Pro Max ne semble pas suffisamment flexible pour reproduire directement un tunnel ou un routage Free Pro non standard ;
• la prochaine étape logique est un test avec Linux, VyOS ou MikroTik en conservant l’ONU Free ;
• le WAS-110 sera pertinent ensuite, uniquement pour supprimer l’ONU, une fois la couche IP entièrement fonctionnelle.

Je commencerais donc par obtenir une connectivité IPv6 complète sous Linux sur le VLAN 836, puis par reproduire exactement l’adressage et les routes observés sur la Freebox. Ensuite seulement, j’analyserais la construction de l’IPv4 sur le VLAN 301.

Tu es clairement arrivé au point où une capture complète de démarrage de la Freebox devrait permettre de débloquer l’analyse.

Bonjour à tous,

Je sollicite votre aide sur un bypass SFR XGS-PON avec un WAS-110 (firmware 8311).

J'ai une **Box 10+ SERCOMM (Vendor ID : SCOM)**, contrairement à la plupart des retours du sujet qui concernent des modèles PTIN/XSR150DX.

### Configuration

- WAS-110
- Firmware 8311 Community v2.8.x
- MIB : `prx300_1U.ini`
- OMCC : `0xA0`
- OMCI Mask : `18`

### Symptômes

- L'ONU passe correctement en **O5.1 (Associated)**.
- Le lien Ethernet est établi.
- Mon routeur envoie bien les DHCP Discover.
- Aucun DHCPOFFER en retour.
- Le WebUI du firmware affiche **"No Extended VLAN Tables Detected"**.

J'ai déjà testé différentes combinaisons (OMCC, Equipment ID vide/renseigné, etc.) sans changement.

### Ma question

Est-ce que quelqu'un a réussi un bypass avec une **Box 10+ SERCOMM (Vendor SCOM)** ?

Je cherche surtout à connaître les **vraies valeurs OMCI** utilisées par cette Box, notamment :

- Equipment ID
- Hardware Version
- Software Version A/B (ME7)
- Circuit Pack / ONU2-G

Ou bien un retour d'expérience d'une personne ayant réussi avec une Box SERCOMM.

J'ai l'impression que tous les exemples publics concernent des Box PTIN, alors que dans mon cas l'OLT authentifie bien l'ONU (O5.1) mais ne provisionne jamais le service DATA (pas d'Extended VLAN Tables).

Merci d'avance si quelqu'un a déjà rencontré ce cas ou possède une Box 10+ SERCOMM.

avec les infos que je t'ai donné tu as pu réussir ?

Parfait top merci !

Bonjour, Autoforest,
merci de ce retour sur le MLO mais normalement le wifi reste activé en permanence je testerai et activerai le MLO sur ma box et je vous redirai si sa le fait ou non la meme chose ou pas la moi j'attebd la misexa jour 1 1.8.12 du repeteur wifi7 etabt donné que j'ai reçu la G03.R08.C03_00 lundi et samedi jecre-teste le mode WPA3 personal Compatibility ( Recommandé ) voir si il a ete corriger voir si il active ou non le wifi7 donc le logo7 sur mon S25 ultra et le WPA3 au lieu du WPA2 actuel sur le repeteur wifi7 je vous tien informer

Tu pourrais essayer en wifi si tu as un téléphone récent voir si tu dépasses, ou même brancher l'ordi sur un port 1gb, mais à mon avis tu auras pareil.
Hormis un changement de box Free ne pourra pas faire plus pour toi, malheureusement...