Remplacement SFR Box 8X / Gateway XGS-PON par WAS-110 — configuration fonctionnelle en IPv4

Bonjour à tous,

Je partage ici un retour d’expérience sur le remplacement d’une gateway SFR XGS-PON / Box 8X par un module WAS-110 sous firmware 8311.

L’objectif était de faire monter l’accès Internet directement sur mon routeur personnel, sans passer par la box opérateur.

À ce stade, la configuration est fonctionnelle en IPv4 uniquement.
L’IPv6, la TV et la téléphonie ne sont pas encore validées dans ce retour.

1. Contexte

Accès concerné :

• Accès SFR XGS-PON
• IPv4 full stack fixe
• Pas de CG-NAT
• Remplacement de la gateway opérateur par un WAS-110
• Routeur personnel derrière le WAS-110
• Firmware 8311 sur le WAS-110

Attention : les valeurs ci-dessous sont volontairement anonymisées.
Il ne faut évidemment pas recopier les identifiants d’un autre accès. Il faut utiliser les informations propres à sa ligne.

2. Informations importantes récupérées depuis l’ONT / gateway officielle

Le point clé a été de comparer ce que l’OLT voyait avec la gateway officielle fonctionnelle, puis avec le WAS-110.

Côté OLT, la gateway officielle remontait notamment :

vendor-id          : PTIN
equip-id           : XSR150DX
sernum             : PTIN:XXXXXXXX
eqpt-ver-num       : 3NTRGW22161P00
version-number     : 3NTRGW22161P00
sw-ver-act         : 3HDMSW00000000
sw-ver-psv         :
actual-us-rate     : 10g
template-name      : DEFAULT
auto-prov-status   : not-applicable

Avec une configuration incorrecte du WAS-110, l’ONT était bien vu, mais certaines valeurs n’étaient pas alignées :

eqpt-ver-num       : 00000000000000
version-number     : 00000000000000
sw-ver-act         : FE7SWxxxxxxxx
sw-ver-psv         : FE7SWxxxxxxxx

Dans cet état, l’OMCI dialoguait bien, mais le service Internet ne montait pas correctement.

3. Configuration 8311 fonctionnelle côté WAS-110

Voici les paramètres qui ont permis de faire fonctionner l’accès IPv4.

À adapter avec les valeurs propres à votre ligne.

PON Serial Number / ONT ID :
PTINXXXXXXXX

Vendor ID :
PTIN

Equipment ID :
XSR150DX

Hardware Version :
3NTRGW22161P00

Sync Circuit Pack Version :
activé

Software Version A :
0.0

Software Version B :
3HDMSW00000000

Firmware Version Match :
vide

Firmware Match Number :
1

Override active firmware bank :
vide

Override committed firmware bank :
vide

PON Mode :
XGS-PON

OMCC Version :
0xA0

OMCI Interoperability Mask :
18

Registration ID HEX :
valeur propre à votre ligne, anonymisée ici

Logical ONU ID :
vide

Logical Password :
vide

MIB File :
/etc/mibs/prx300_1U.ini

PON Slot :
vide

IP Host MAC Address :
MAC de la gateway / ONT officiel, anonymisée ici

IP Host Hostname :
vide

IP Host Domain Name :
vide

Point important : dans mon cas, la valeur Software Version A = 0.0 et Software Version B = 3HDMSW00000000 permet d’obtenir côté OLT :

sw-ver-act : 3HDMSW00000000
sw-ver-psv : 0.0

C’est ce comportement qui a permis d’aller plus loin dans le provisioning.

4. Résultat côté OLT après correction

Après modification de la configuration 8311, le WAS-110 remonte ainsi côté OLT :

vendor-id          : PTIN
equip-id           : XSR150DX
sernum             : PTIN:XXXXXXXX
eqpt-ver-num       : 3NTRGW22161P00
version-number     : 3NTRGW22161P00
sw-ver-act         : 3HDMSW00000000
sw-ver-psv         : 0.0
auto-sw-planned-ver  : 3HDMSW00000000
auto-sw-download-ver : 3HDMSW00000000
actual-us-rate     : 10g
template-name      : DEFAULT
auto-prov-status   : not-applicable

Les valeurs suivantes restent différentes de la gateway officielle, mais ne semblent pas bloquantes pour l’IPv4 dans mon cas :

actual-num-slots   : 1 au lieu de 2
num-tconts         : 16 au lieu de 8
num-trf-sched      : 8 au lieu de 0
num-prio-queues    : 128 au lieu de 0

5. Table VLAN reçue via OMCI

Une fois la configuration corrigée, le WAS-110 reçoit une table Extended VLAN.

Dans mon cas, la table pousse du VLAN 101.

Extrait logique :

Extended VLAN table 257

Trafic non tagué IPv4 IPoE  -> VLAN 101
Trafic non tagué autre      -> VLAN 101
Trafic tagué VID 101        -> VLAN 101
Trafic tagué VID 0          -> VLAN 101

Interprétation : le WAS-110 reçoit bien une règle de translation/traitement VLAN côté OMCI.

Dans mon cas, il ne faut pas nécessairement tagger le VLAN 101 côté routeur. Le trafic non tagué côté client est pris en charge par la table OMCI et envoyé vers le VLAN attendu côté réseau.

6. Configuration routeur

Côté routeur personnel, la configuration fonctionnelle IPv4 est simple :

WAN IPv4 :
DHCP

VLAN WAN :
aucun / non tagué

IPv6 :
non validé à ce stade

Authentification PPPoE :
non

Mode :
IPoE / DHCP

Dans mon cas, l’IPv4 publique remonte correctement en DHCP.

7. Capture OMCI

Pour diagnostiquer, la capture OMCI est extrêmement utile.

Sur le WAS-110 :

tcpdump -i gem-omci -s0 -U -w /tmp/omci.pcap

La bonne méthode est de lancer la capture avant de déclencher la séquence PON :


1. Débrancher la fibre
2. Se connecter au WAS-110
3. Lancer tcpdump sur gem-omci
4. Rebrancher la fibre
5. Attendre 1 à 2 minutes
6. Stopper tcpdump avec CTRL+C
7. Récupérer le fichier PCAP
   
Sous Windows, avec OpenSSH récent, il peut être nécessaire de forcer l’ancien mode SCP, car le WAS-110 n’a pas forcément de serveur SFTP :

scp -O [root@192.168.x.x](mailto:root@192.168.x.x):/tmp/omci.pcap C:\omci.pcap

8. Vérification de la table VLAN

Commande utile côté WAS-110 :

8311-extvlan-decode.sh -t

Elle permet de vérifier si l’OLT a bien poussé une table Extended VLAN.

Dans mon cas, l’arrivée de la table VLAN 101 a été un très bon indicateur : avant correction des versions software/hardware, le service ne semblait pas correctement provisionné.

9. Commandes utiles de diagnostic

État PON :

pontop -b -g s

Compteurs PLOAM :

pontop -b -g "PLOAM Downstream Counters"
pontop -b -g "PLOAM Upstream Counters"

Interface OMCI :

ip link show gem-omci
ip -s link show gem-omci

Capture DHCP côté routeur / WAN :

tcpdump -i ethX -e -n -vvv -s0 'udp port 67 or udp port 68 or udp port 546 or udp port 547 or arp or icmp6'

10. Procédure de récupération en cas de configuration cassée

En cas de mauvaise configuration des variables 8311, par exemple si l’ONT devient incohérent côté OLT ou si la version software remonte mal, on peut supprimer les variables 8311 et repartir proprement.

Afficher les variables :

fw_printenv | grep '^8311'

Supprimer les variables 8311 :

fw_printenv | awk -F'=' '/^8311/ {print $1}' | xargs fw_setenv
reboot

Après reboot, il faut reconfigurer proprement les paramètres nécessaires.

11. Points non encore validés

À ce stade, je valide uniquement :

• Synchronisation XGS-PON
• Dialogue OMCI
• Provisioning VLAN via OMCI
• IPv4 publique via DHCP
• Accès Internet IPv4 fonctionnel

Non encore validé :

• IPv6 / DHCPv6-PD
• Décodeur TV officiel
• Téléphonie
• Trunk SIP éventuel vers FreePBX

12. Conclusion

Le point bloquant principal n’était pas le serial ou le Vendor ID, mais l’alignement des informations hardware/software vues côté OLT.

Les valeurs importantes dans mon cas sont :

vendor-id        : PTIN
equip-id         : XSR150DX
hardware version : 3NTRGW22161P00
software active  : 3HDMSW00000000
PON mode         : XGS-PON
OMCC version     : 0xA0
MIB file         : /etc/mibs/prx300_1U.ini
OMCI mask        : 18

Une fois ces valeurs correctement présentées, l’OLT a poussé une table Extended VLAN avec le VLAN 101, puis l’IPv4 est montée correctement en DHCP sur le routeur personnel.

Encore merci aux personnes qui m’ont aidé à analyser les échanges OMCI et les retours côté OLT. La comparaison entre la gateway officielle et le WAS-110 a été déterminante.

et maintenant il me reste à régler le problème de l'IPv6...

ok avec toi, mais côté réseau mon contact m'a précisé qu'en XGS il attend que le Vlan 101 au final.

le 102 peut être la TV ? (mais techniquement je m'en fout : appli SFR TV ou connect TV / c'est OK)