Bon, je pense avoir trouvé la cause : mon routeur Mesh connecté derrière le routeur Starlink bypassé ! Du coup, j'ai supprimé le bypass et connecté mon Mesh en point d'accès, ca fonctionne !

Par contre, j'aimerais comprendre quel était le problème puisque ça marchait l'an dernier !...

j'ai suivi ton conseil sur le boitier noir que j'ai reçu merci.
les leds sont toutes au vert mais je n'ai toujours pas de trafic...
je vois pas le problème...

Oui...

Update tests WAS-110 / SFR XGS-PON / Box 8X

Petit complément après une nouvelle série de tests sur un bypass de Box SFR 8X XGS-PON avec un WAS-110 firmware 8311.

L’objectif reste :

Fibre SFR XGS-PON
→ WAS-110 / 8311
→ UDM-SE / UDM

1. Configuration WAS actuellement testée

Configuration 8311 utilisée côté WAS :

PON Serial Number        : PTINXXXXXXXX
Vendor ID                : PTIN
Equipment ID             : XSR150DX
Hardware Version         : 3NTRGWXXXXXXXX
Sync Circuit Pack Version: activé
Software Version A       : 3XGS020803R0B
Software Version B       : 3XGS020803R0B
PON Mode                 : XGS-PON
OMCC Version             : 0xA0
OMCI Interoperability Mask : 18
Registration ID HEX      : XXXXXXXX  (SLID converti en HEX)
MIB File                 : /etc/mibs/prx300_1V.ini
IP Host MAC Address      : XX:XX:XX:XX:XX:XX

Données à remplacer par chacun :

PTINXXXXXXXX             = Serial PON / ONT ID
3NTRGWXXXXXXXX           = Version matériel récupérée depuis la box
3XGS020803R0B            = Version logiciel récupérée depuis la box
XXXXXXXX                 = SLID converti en HEX
XX:XX:XX:XX:XX:XX        = MAC WAN de la box

Le WAS monte bien en O5.1 :

PON PLOAM Status : O5.1, Associated state
FEC upstream     : ON
FEC downstream   : ON

2. État OMCI / GEM

Toujours le même blocage : le PON monte, l’OMCI de gestion fonctionne, mais pas de service DATA visible.

GEM/XGEM observé :

GEM Index : 0
GEM ID    : 67
Alloc ID  : 67
Type      : OMCI
Direction : DS + US

Pas de GEM DATA supplémentaire.

Dans les VLAN Tables :

No Extended VLAN Tables Detected

Donc état actuel :

PON O5.1       : OK
OMCI           : OK
GEM OMCI       : OK
GEM DATA       : absent
VLAN Tables    : absentes
DHCP Offer     : absent

3. Option 60 DHCP identifiée

Une info intéressante côté opérateur : le Vendor Class ID qui semble attendu lorsque la box est vue correctement ressemble à :

neufbox_ALGX1-ALB-r2_3XGS020803R0B

J’ai donc remplacé l’ancienne option 60 par cette valeur.

Côté UDM, avec VLAN 101, MAC clone et option 60 correcte, le Discover sort proprement :

VLAN              : 101
Client MAC        : MAC WAN de la box
Option 60         : neufbox_ALGX1-ALB-r2_3XGS020803R0B
Option 61         : ether MAC WAN de la box
DHCP Message Type : Discover

Exemple tcpdump anonymisé :

0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP Discover
Client-Ethernet-Address XX:XX:XX:XX:XX:XX
Vendor-Class (60): "neufbox_ALGX1-ALB-r2_3XGS020803R0B"
Client-ID (61): ether XX:XX:XX:XX:XX:XX
VLAN 101

4. Découverte côté UDM : Requested-IP 192.168.20.11

Lors des tests, l’UDM relançait automatiquement son client DHCP WAN avec une option 50 étrange :

Requested-IP (50): 192.168.20.11

En cherchant côté UDM, on voit que le process lancé par ubios-udapi-server contient explicitement :

/usr/bin/busybox-legacy/udhcpc
--interface eth9
-r 192.168.20.11
--vendorclass "neufbox_ALGX1-ALB-r2_3XGS020803R0B"

Cette IP ne correspond pas à mon LAN ni à l’IP privée de la box SFR. Je ne sais pas encore si c’est normal côté UDM, un ancien bail, un état WAN pollué, ou autre.

Après reboot de l’UDM, le DHCP Discover est redevenu propre : plus de Requested-IP 192.168.20.11.

5. Tests réalisés

Tests effectués :


1. WAS avec MIB prx300_1V.ini
2. OMCC 0xA0
3. VLAN 101 porté par l’UDM
4. MAC clone de la box sur l’UDM
5. Option 60 : neufbox_ALGX1-ALB-r2_3XGS020803R0B
6. Option 61 : Client-ID basé sur la MAC box
7. IPv6 désactivé temporairement
   
Résultat :

DHCP Discover sortant OK sur VLAN 101
Pas de DHCP Offer vu côté UDM
Pas de GEM DATA visible côté WAS
Pas de VLAN Table côté WAS

Test alternatif tenté :

UDM sans VLAN
WAS ISP Fix / VLAN Fix testé
Option 60 identique
MAC clone identique

Résultat :

DHCP Discover sortant non taggé OK
Pas de DHCP Offer
Pas de preuve que le flux remonte correctement côté opérateur

6. Piste principale actuelle

À ce stade, le DHCP côté UDM semble propre lorsqu’on élimine l’Option 50 parasite.

Le blocage semble plutôt être côté OMCI / provisioning DATA :

L’OLT accepte l’ONU au niveau PLOAM / O5.1
L’OMCI de gestion fonctionne
Mais l’OLT ne pousse pas de GEM DATA ni de VLAN Tables

Hypothèses restantes :


* Profil MIB incomplet ou incorrect
* Equipment ID / ONU2-G encore mal exposé
* MEs vendor-specific attendues par SFR / PTIN / Altice
* Besoin de replacements.ini / spoof OMCI comme dans certains bypass MEO/PTIN
* PON Slot à tester
* OMCI Interoperability Mask à tester, par exemple 26
 
7. Questions ouvertes

Si quelqu’un a déjà avancé sur SFR XGS-PON / Box 8X / XSR150DX avec WAS-110, je cherche surtout à comprendre :


1. Quelle MIB fonctionne réellement : 1U, 1V, 2U, autre ?
2. Faut-il faire apparaître XSR150DX dans ONU2-G Equipment ID ?
3. Faut-il plutôt utiliser ALGX1-ALB-r2 dans certains champs OMCI ?
4. Est-ce que certains obtiennent un GEM DATA avec SFR XGS-PON ?
5. Est-ce que SFR/PTIN attend des MEs vendor-specific absentes du WAS ?
6. Quelqu’un a-t-il un replacements.ini fonctionnel ou une comparaison OMCI box vs WAS ?
7. Le Requested-IP 192.168.20.11 côté UDM est-il connu/normal ?
   

Bonjour,

as tu essayé cette option https://mabbox.bytel.fr/wireless
"Wi-Fi secondaire
Le Wi-Fi compatible avec les appareils les plus anciens."