Auteur Sujet: Remplacer ONT SFR (Lu 225401 fois)

artemus24 · « **Réponse #1032 le:** 05 décembre 2024 à 21:32:10 »

Merci hwti pour tes conseils qui m'ont permis de résoudre mon principale problème.

Je ne me suis pas souvenu que la première fois où j'ai eu l'accès à l'internet, j'avais tapé toutes les commandes du didacticiel Carlito dans "Gpon Hack", dans l'ordre d'apparition.

@ Rooot : De toute façon, mon dongle USB/RJ45 est bleu (2.5gb/s) sinon il serait vert (1gb/s).
Je vérifie quand même. Je passe par mon convertisseur USB SERIAL-TTL.

Code: [Sélectionner]

FALCON => printenv sgmii_mode
sgmii_mode=5
FALCON =>

Je suis bien en mode 5, donc bien en 2.5gb/s.
Y-a-t-il une quelconque configuration que je dois indiquer à l'OLT pour travailler en 2.5gb/s et non en 1gb/s ?

Citation de: Rooot

Maximushugus est il sur une offre 2Gbps ?

Dans le sujet, Asclèpios pose la question pour du 2gb/s. Je crois que c'est là que MaximumHugus répond qu'il est dans une offre à 1gb/s.

J'utilise normalement mon câble éthernet catégorie 5e de 10m de long, pour les connexion.
J'ai vérifié en mettant un câble éthernet catégorie 6a de 0.50m. Pareil, pas d'accès à l'ONU.
C'est le paramétrage qui est en cause puisque j'avais l'accès à l'ONU en 2.5gb/s (dongle USB/RJ45 couleur bleu).

Citation de: hwti

Normalement sfp_a2_info ne sert que pour le firmware Huawei d'origine (ou rooté).

Avant de basculer dans la version Carlito, j'ai bidouiller avec "sfp_a2_info". J'ai juste ajouter l'adresse MAC qui n'était pas présente, et je n'y ai plus touché.

Citation de: hwti

A voir ce que tu as au final dans "omci_pipe.sh mda" (juste le SN ?).

Le "serial number" est celui de ma BOX 8 SFR. Il a toujours été présent, même quand je consulte en faisant :

Code: [Sélectionner]

root@SFP:~# omci_pipe.sh meg 256 0
Class ID    = 256 (ONU-G)
Instance ID = 0
Upload      = yes
Alarms      = 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
              0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
-------------------------------------------------------------------------------
 0 Vendor id                     4b STR  R--A---P---
   0x5a 0x4d 0x00 0x00
   ZM\x00\x00
-------------------------------------------------------------------------------
 1 Version                      14b STR  R--A---P---
   0x53 0x46 0x50 0x2d 0x50 0x30 0x35 0x00 0x00 0x00 0x00 0x00 0x00 0x00
   SFP-P05\x00\x00\x00\x00\x00\x00\x00
-------------------------------------------------------------------------------
 2 Serial number                 8b STR  R--A---P---
   0x50 0x54 0x49 0x4e 0xa8 0x18 0x84 0x7f
   PTIN\xAA\xBB\xCC\xDD
-------------------------------------------------------------------------------
 3 Traffic management opt        1b ENUM R----------
   0x00 (0)
-------------------------------------------------------------------------------
 4 VP/VC cc function option      1b UINT R---O------
   0x00 (0)
-------------------------------------------------------------------------------
 5 Battery backup                1b UINT RW-------E-
   0x00 (0)
-------------------------------------------------------------------------------
 6 Administrative state          1b UINT RW-------E-
   0x00 (0)
-------------------------------------------------------------------------------
 7 Operational state             1b UINT R--A-----E-
   0x00 (0)
-------------------------------------------------------------------------------
 8 ONU survival time             1b UINT R--------E-
   0x00 (0)
-------------------------------------------------------------------------------
R - Readable          O - Not supported (optional)
W - Writable          E - Excluded from MIB upload (template)
S - set-by-create     T - Table
A - Send AVC          V - Volatile
U - No upload         P - No swap
N - Not suported      Y - Partly supported
N - No swap

errorcode=0
root@SFP:~#

J'ai masqué les huit quartets du serial number et pour information, ils correspondent bien à ceux de ma BOX 8.

Citation de: hwti

Il est possible que ton OLT ne vérifie pas Equipment ID et autres, mais peut-être que d'autres en ont besoin (ça pourrait même dépendre du profil, et donc de quand l'abonnement a été souscrit).

C'est OUI, aucune vérification puisque j'ai l'accès à l'internet.
MaximumsHugus a certainement eu besoin de le faire, mais pas chez moi.

Le NRO a été installé en 2020, je crois, les premiers abonnement datent de septembre 2020, et mon premier abonnement à la fibre date de février 2023.

Citation de: hwti

Tu veux parler de l'upload, non ?

Oui, je parle bien du débit ascendant (upload) qui est faible. Seulement 100mb/s environ.

Citation de: hwti

Dans le tuto il y a bien le "rm /etc/optics/.goi_recovered" pour relire les données de calibration (qui sont écrasées quand on fait un flash d'une image complète).

Je l'ai fait, et c'est "/etc/optic/.goi_recovered" sans le "s" à "optic".

hwti · « **Réponse #1033 le:** 05 décembre 2024 à 22:10:53 »

Citation de: artemus24 le 05 décembre 2024 à 21:32:10

@ Rooot : De toute façon, mon dongle USB/RJ45 est bleu (2.5gb/s) sinon il serait vert (1gb/s).
Je vérifie quand même. Je passe par mon convertisseur USB SERIAL-TTL.
Code: [Sélectionner]
FALCON => printenv sgmii_mode sgmii_mode=5 FALCON =>Je suis bien en mode 5, donc bien en 2.5gb/s.
Y-a-t-il une quelconque configuration que je dois indiquer à l'OLT pour travailler en 2.5gb/s et non en 1gb/s ?

Le mode 5 c'est une auto-détection 1Gbps / 2.5Gbps.
On peut vérifier le mode courant avec "onu lanpsg 0" : link_status=3 (ou 4) pour 1Gbps, link_status=5 pour 2.5Gbps.

Au besoin, tu peux tester de forcer le 2.5Gbps, il y a deux possibilités :
- "fw_setenv sgmii_mode 2" : en cas d'échec, il faudra le port série pour récupérer
- "onu lanpcs 0 1 -1 4 3 1 0 5 0 0 9216 1 0 0 0" : ça correspond aux réglages qui seraient appliqués par le mode 2, ça permet donc de tester (tout en retournant en mode 5 au reboot)

Citation de: artemus24 le 05 décembre 2024 à 21:32:10

Je l'ai fait, et c'est "/etc/optic/.goi_recovered" sans le "s" à "optic".

Et est-ce que les valeurs données par "otop" semblent normales ?

artemus24 · « **Réponse #1034 le:** 05 décembre 2024 à 23:22:04 »

J'ai un peu progressé. J'ai fait un "firstboot" puis un "reboot". J'ai dû entrer le Password (ou Ploam) en hexadécimal par la commande "uci set gpon.ploam.nSerial=..." puis faire "uci commit gpon.ploam.nSerial". Et ensuite faire un reboot pour que cela soit effectivement validé.

Je confirme, pas besoin du "target" car le but de cette manipulation était de supprimer toutes les modifications que j'avais faites.

J'ai cru qu'il suffisait de basculer le bouton de ON sur OFF pour que cela applique le passage de 1gb/s à 2.5gb/s. Et ben non. Le bouton doit être sur OFF et je dois éteindre le Media Converter puis le rallumer. Le voyant Fx s'allume et c'est bon maintenant, je suis bien en 2.5gb/s.

Code: [Sélectionner]

root~> speedtest

   Speedtest by Ookla

      Server: BOUYGUES TELECOM BBR - Bordeaux (id: 58159)
         ISP: SFR
Idle Latency:    31.04 ms   (jitter: 2.78ms, low: 27.56ms, high: 33.39ms)
    Download:  1875.75 Mbps (data used: 2.6 GB)                                                   
                113.50 ms   (jitter: 44.05ms, low: 24.69ms, high: 1087.96ms)
      Upload:    98.51 Mbps (data used: 92.4 MB)                                                   
                 25.65 ms   (jitter: 1.07ms, low: 24.33ms, high: 30.57ms)
 Packet Loss:     0.0%
  Result URL: https://www.speedtest.net/result/c/b61ec04a-5aff-4209-8946-d84b7e85a075
root~>

Il faut le savoir ! Je n'ai pas encore la connaissance de toutes les manipulations à faire pour produire le résultat escompté. :'(

Il me reste plus qu'à résoudre ce problème de débit ascendant (Upload) qui est faible. Mais là, je sèche totalement.
J'ai bien supprimé le fichier "/etc/optic/.goi_recovered".

Citation de: Hwti

Et est-ce que les valeurs données par "otop" semblent normales ?

Si tu parles vis-à-vis de ce que j'avais dans la BOX 8 SFR, non, pas normal, mais meilleur.

Code: [Sélectionner]

RSSI 1490 power				19.02uW -17.09dBm
tx power (se* (bias + mod/2-ith))	0.36mW -4.48dBm

hwti · « **Réponse #1035 le:** 05 décembre 2024 à 23:41:26 »

Citation de: artemus24 le 05 décembre 2024 à 23:22:04

Il me reste plus qu'à résoudre ce problème de débit ascendant (Upload) qui est faible. Mais là, je sèche totalement.
J'ai bien supprimé le fichier "/etc/optic/.goi_recovered".
Si tu parles vis-à-vis de ce que j'avais dans la BOX 8 SFR, non, pas normal, mais meilleur.
Code: [Sélectionner]
RSSI 1490 power 19.02uW -17.09dBm tx power (se* (bias + mod/2-ith)) 0.36mW -4.48dBm

Le /etc/optic/.goi_recovered a bien été recréé après reboot ?
Le -4.48dBm en émission me semble anormalement faible, ca ressemble au cas de @larod241 qui avait plafonnait à 150Mbps avec -0.69dBm.
Une fois les données de calibration récupérées, il était remonté à 1.81dBm, mais bizarrement ça n'avait pas eu un effet immédiat (il avait fallu débrancher la fibre 15 min, et ensuite les débits étaient normaux, je ne sais pas ce que ça peut avoir fait).
https://lafibre.info/remplacer-livebox/guide-de-connexion-fibre-directement-sur-un-routeur-voire-meme-en-2gbps/msg1095551/#msg1095551

Normalement tu n'as jamais dû écraser mtd1, mais au cas où si tu as bien fait le backup de la partition au tout début, on peut vérifier la valeur de goi_config dedans, pour la comparer à "fw_printenv goi_config".
On peut aussi comparer les /etc/config/goi_config, /etc/config/goi_age et /etc/config/goi_table_laser_ref.csv avec le contenu extrait de ta variable (ce qui est censé être fait au boot après avoir effacé /etc/optic/.goi_recovered).

Depuis le backup :

Code: [Sélectionner]

strings mtd1 | grep -m1 goi_config | sed "s/^goi_config=//" | tr '@' '\n' | uudecode -o goi.tar.gz
tar xf goi.tar.gz

Depuis la variable :

Code: [Sélectionner]

fw_printenv -n goi_config | tr '@' '\n' | uudecode -o goi.tar.gz
tar xf goi.tar.gz

artemus24 · « **Réponse #1036 le:** 06 décembre 2024 à 05:56:45 »

Quand je disais que j'avais un meilleur résultat, c'est avec "RSSI 1490 power" puisque la BOX me donne plutôt du "-23.00dBm" alors que l'ONU me donne "-17.00dBm".

Tu m'as fait douté sur la valeur du "tx power". Elle est bien de l'ordre de "-4.00dBm", donc oui, elle est faible.
J'ai supprimé le fichier "/etc/optic/.goi_recovered" puis "reboot". Le fichier est recréé mais je suis toujours sur le même ordre de grandeur, parfois un peu mieux.
Mais après un Speedtest, je tombe autour de "-3.00dBm" parfois vers les "-4.00dBm". Puis j'ai tenté de faire :

Code: [Sélectionner]

root@SFP:/etc/optic# /etc/init.d/recover_goi.sh stop
root@SFP:/etc/optic# la
drwxr-xr-x    1 root     root             0 Jun 27 02:21 .
drwxr-xr-x    1 root     root             0 Jun 27 02:16 ..
-rw-r--r--    1 root     root             0 Jun 27 02:21 .goi_recovered
-rwxr-xr-x    1 root     root             1 May 29  2016 goi_age
-rw-r--r--    1 root     root           120 Jul  4  2016 goi_table_laser_ref.csv
-rw-r--r--    1 root     root           120 Jul  4  2016 goi_table_laser_ref_base.csv
-rwxr-xr-x    1 root     root            72 Jun 27 02:12 goi_table_rssi1490_corr.csv
-rwxr-xr-x    1 root     root           113 Jun 27 02:12 goi_table_text_corr.csv
-rw-r--r--    1 root     root            64 Jul  4  2016 goi_table_vapd_bd.csv
root@SFP:/etc/optic# rm .goi_recovered
root@SFP:/etc/optic# /etc/init.d/recover_goi.sh reload
Recover goi_config from U-Boot
root@SFP:/etc/optic# 
root@SFP:/etc/optic# /etc/init.d/recover_goi.sh start
root@SFP:/etc/optic#

mais j'obtiens toujours le même résultat.

J'ai alors supprimé le fichier "/etc/optic/.goi_recovered" et j'ai arrêté l'onu environ 15 minutes, puis redémarré comme indiqué.
Cela n'a rien changé. Mon débit ascendant ne dépasse pas les 150mb/s.

hwti · « **Réponse #1037 le:** 06 décembre 2024 à 10:26:20 »

Citation de: artemus24 le 06 décembre 2024 à 05:56:45

Quand je disais que j'avais un meilleur résultat, c'est avec "RSSI 1490 power" puisque la BOX me donne plutôt du "-23.00dBm" alors que l'ONU me donne "-17.00dBm".

Ca ne me semble pas normal d'avoir une telle différence, donc la mesure de l'ONU est probablement incorrecte.

Citation de: artemus24 le 06 décembre 2024 à 05:56:45

Tu m'as fait douté sur la valeur du "tx power". Elle est bien de l'ordre de "-4.00dBm", donc oui, elle est faible.
J'ai supprimé le fichier "/etc/optic/.goi_recovered" puis "reboot". Le fichier est recréé mais je suis toujours sur le même ordre de grandeur, parfois un peu mieux.

Est-ce que tu as un backup des mtd d'origine (avant toute modification) ?
Si oui, on peut comparer :
- le goi_config qu'il y a dans le mtd1 (normalement ce qu'on vient de restaurer, mais il est préférable de vérifier)
- le contenu des /etc/optic des deux images (peut-être "plus à jour" que les données goi_config, je ne sais pas exactement)
- ce que tu as actuellement dans /etc/optic

artemus24 · « **Réponse #1038 le:** 06 décembre 2024 à 22:01:24 »

Voici ce que j'ai dans la BOX 8 SFR :
--> Puissance optique reçue : -23.2 dBm
--> puissance optique transmise : 4.2 dBm

Citation de: htwi

Est-ce que tu as un backup des mtd d'origine (avant toute modification) ?

Oui, j'ai une sauvegarde des six partitions de mtd0 à mtd5 en faisant depuis l'ONU :
"dd if=/dev/mtdx of=/tmp/mtdx.backup"
puis ensuite récupération des fichiers et stockage dans Windows.

Citation de: htwi

Normalement tu n'as jamais dû écraser mtd1, mais au cas où si tu as bien fait le backup de la partition au tout début, on peut vérifier la valeur de goi_config dedans, pour la comparer à "fw_printenv goi_config".

Comment veux tu que je vérifie quoi que ce soit ?

J'ai une question concernant la restauration des partitions que j'ai sauvegardées.
Pour installer l'image 0 du micrologiciel Carlito, j'ai récupéré le fichier depuis le site "Hack Gpon" et j'ai fait ceci :

Code: [Sélectionner]

mtd -e image0 write /tmp/mtd2.bin image0Mais si je veux installer la partition mtd1, je fais comment ? Peut-être ceci :

Code: [Sélectionner]

mtd -e uboot_env write /tmp/mtd1.backup uboot_envdepuis n'importe quelle image ou nécessairement depuis l'image 1 ?

Du coup, je ne comprends pas trop comment réinstaller la partition nommée "rootfs_data" ?
C'est la partition "mtd4" pour l'image 0 ou la partition "mtd5" pour l'image 1.

De même, comment réinstaller la partition nommée "rootfs" ?
C'est la partition "mtd3" pour l'image 0 ou la partition "mtd4" pour l'image 1.

Citation de: htwi

Ca ne me semble pas normal d'avoir une telle différence, donc la mesure de l'ONU est probablement incorrecte.

Je veux bien mais j'ai tenté de restaurer le calibrage en supprimant le fichier "/etc/optic/.goi_recevered".
J'ai parfois une valeur positive, mais après le "speedtest", elle devient négative et j'ai quand même un mauvais debit ascendant (upload).

Citation de: htwi

Si oui, on peut comparer :

Quand tu fais un "firstboot", normalement tous les fichiers sont écrasés (ou remplacés) par ceux dans "/rom", même ceux présents dans "/etc/optic/".
Je pense que cela ne va rien changé au problème, si dès le départ le problème se situe dans les fichiers.

hwti · « **Réponse #1039 le:** 07 décembre 2024 à 00:24:33 »

Citation de: artemus24 le 06 décembre 2024 à 22:01:24

Comment veux tu que je vérifie quoi que ce soit ?

En manuel :

Code: [Sélectionner]

strings mtd1.bin | grep goi_config

En plus complet :
Créer un "fw_env.config" avec :

Code: [Sélectionner]

mtd1.bin 0x0 0x10000
mtd1.bin /dev/mtd1 0x40000 0x10000

(c'est sur le modèle du /etc/fw_env.config qui est dans le firmware, il y a deux zones utilisées alternativement)
Et ensuite :

Code: [Sélectionner]

fw_printenv -c fw_env.config goi_config

Pour la restauration des partitions, j'ai répondu sur l'autre thread.

Citation de: artemus24 le 06 décembre 2024 à 22:01:24

Je veux bien mais j'ai tenté de restaurer le calibrage en supprimant le fichier "/etc/optic/.goi_recevered".
J'ai parfois une valeur positive, mais après le "speedtest", elle devient négative et j'ai quand même un mauvais debit ascendant (upload).

Donc peut-être pour une raison inconnue la valeur de la variable goi_config a été modifiée, ou alors elle ne convient plus (vieillissement ?).

Citation de: artemus24 le 06 décembre 2024 à 22:01:24

Quand tu fais un "firstboot", normalement tous les fichiers sont écrasés (ou remplacés) par ceux dans "/rom", même ceux présents dans "/etc/optic/".
Je pense que cela ne va rien changé au problème, si dès le départ le problème se situe dans les fichiers.

Je n'ai jamais parlé de faire un firstboot, ni d'ailleurs de reflasher à l'aveugle (le problème reviendrait en cas de retour au firmware Carlito derrière) mais de regarder ce qu'il y a dans tes backups, et d'aviser.
Peut-être qu'on va trouver des données plus récentes que dans la variable goi_config, et qu'il sera intéressant de juste copier ces fichiers.

Là on a jusqu'à 4 jeux des fichiers à comparer (il est probable que plusieurs soient identiques) :
- la variable goi_config actuelle
- la variable goi_config depuis le mtd1.bin sauvegardé
- le /etc/config du backup image0 (mtd2)
- le /etc/config du backup image1 (mtd5 s'il s'agissait d'un boot sur image0, ou mtd3 s'il s'agissait d'un boot sur image1)

On peut utiliser "binwalk -e mtd2.bin" (avec les outils jefferson et sasquatch installés) pour extraire les images.
Le /etc/optic est constitué deux deux parties :
- les fichiers par défaut sans l'image squashfs
- les modifications / suppressions dans le JFFS2 (qui est monté en overlay)

artemus24 · « **Réponse #1040 le:** 09 décembre 2024 à 01:18:08 »

En manuel, j'ai comparé tous les goi_config que j'ai pu trouvé (dans l'image 0, l'image 1 et dans les backup) et ils sont tous identiques.

Citation de: hwti

En plus complet :
Créer un "fw_env.config" avec :
Code: [Sélectionner]
mtd1.bin 0x0 0x10000 mtd1.bin /dev/mtd1 0x40000 0x10000(c'est sur le modèle du /etc/fw_env.config qui est dans le firmware, il y a deux zones utilisées alternativement)
Et ensuite :
Code: [Sélectionner]
fw_printenv -c fw_env.config goi_config

Je n'ai pas compris ce que tu me demandes de faire ? Je suis sous Carlito, et ta seconde commande ne fonctionne pas.

Est-ce normal que non branché à la fibre, j'ai ce résultat pour "txpower" ?

Code: [Sélectionner]

RSSI 1490 power                 0.00uW -infdBm
tx power (se*(bias+mod/2-ith))  1.36mW 1.34dBm

Je m'attendais plutôt à -infdBm que 1.34dBm, pour "tx power".

Pour ce qui est de la faiblesse de la puissance du laser, est ce due essentiellement à un problème de calibrage ? Le fait de supprimer "/etc/optic/.goi_recovered" semble ne être suffisant. Ou bien est-ce peut être dû à l'ONU Huawei, à la jarretière, au Media Converter, au micrologiciel Carlito, ailleurs ? Si je me procure le "FS P/N: GPON-ONU-34-20BI", est-ce que j'aurai le même problème ?

Sous Debian, J'ai testé le multicast avec VLC et ça ne fonctionne pas. Il est fort possible qu'il manque une quelconque configuration dans l'ONU Huawei SmartAX MA5671a, pour activer le multicast. Est-ce un problème de VLAN ?

Je suis déçu par cet ONU car je m'attendais à une meilleure performance, surtout en ce qui concerne le débit ascendant (upload).

hwti · « **Réponse #1041 le:** 09 décembre 2024 à 02:14:36 »

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

En manuel, j'ai comparé tous les goi_config que j'ai pu trouvé (dans l'image 0, l'image 1 et dans les backup) et ils sont tous identiques.

J'ai un doute sur ce que tu as fait, parce que la variable goi_config, c'est uniquement côté u-boot.
Est-ce que tu as bien pu extraire les /etc/optic des deux backups image0 / image1 ?

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

Je n'ai pas compris ce que tu me demandes de faire ? Je suis sous Carlito, et ta seconde commande ne fonctionne pas.

C'était pour récupérer les variables u-boot depuis un backup, donc c'est sur un PC.

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

Est-ce normal que non branché à la fibre, j'ai ce résultat pour "txpower" ?
Code: [Sélectionner]
RSSI 1490 power 0.00uW -infdBm tx power (se*(bias+mod/2-ith)) 1.36mW 1.34dBmJe m'attendais plutôt à -infdBm que 1.34dBm, pour "tx power".

C'est effectivement bizarre, puisqu'en l'absence de réception le laser n'est pas censé émettre.
Mais j'ai bien des valeurs similaires (2.02dBm avec le G-010S-A, 1.78dBm avec le XO390).

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

Pour ce qui est de la faiblesse de la puissance du laser, est ce due essentiellement à un problème de calibrage ? Le fait de supprimer "/etc/optic/.goi_recovered" semble ne être suffisant. Ou bien est-ce peut être dû à l'ONU Huawei, à la jarretière, au Media Converter, au micrologiciel Carlito, ailleurs ?

Je pars du principe que l'ONU fonctionnait au départ, mais que peut-être que le goi_config n'était pas (plus ?) adapté, et donc c'est pour ça que je demande d'extraire les /etc/optic des backups.
Si la jarretière fonctionne avec la Box 8, alors elle est correcte.

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

Si je me procure le "FS P/N: GPON-ONU-34-20BI", est-ce que j'aurai le même problème ?

Ce serait une solution si ton MA5671A est défectueux, mais pour l'instant on ne sait pas.

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

Sous Debian, J'ai testé le multicast avec VLC et ça ne fonctionne pas. Il est fort possible qu'il manque une quelconque configuration dans l'ONU Huawei SmartAX MA5671a, pour activer le multicast. Est-ce un problème de VLAN ?

Je ne sais pas comment ça fonctionne avec SFR, il y a peut-être des choses à faire sur le routeur.

rooot · « **Réponse #1042 le:** 09 décembre 2024 à 10:12:52 »

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

Sous Debian, J'ai testé le multicast avec VLC et ça ne fonctionne pas. Il est fort possible qu'il manque une quelconque configuration dans l'ONU Huawei SmartAX MA5671a, pour activer le multicast. Est-ce un problème de VLAN ?

j'ai aussi ce problème, souviens-toi, je l'avais évoqué, le problème avait été relevé par d'autres personnes aussi sur un post dans le forum openwrt :
https://forum.openwrt.org/t/support-ma5671a-sfp-gpon/48042/12

Citer

the openwrt just doesn't forward IGMP traffic, normally they have igmpproxy package for that but it require a clear LAN/WAN interface meanwhile the GPON stick doesn't really expose the L2 WAN interface to the openwrt OS so I have no idea how to make it work

Citation de: artemus24 le 09 décembre 2024 à 01:18:08

Je suis déçu par cet ONU car je m'attendais à une meilleure performance, surtout en ce qui concerne le débit ascendant (upload).

Pour moi c'est un souci de configuration quelque part, vu qu'on est une majorité d'utilisateurs à ne pas avoir ce problème. Et tu n'as pas encore testé avec le firmware "fs modded", ce serait bien de le faire avant de donner ton verdict définitif

simon · « **Réponse #1043 le:** 09 décembre 2024 à 10:31:06 »

Citation de: rooot le 09 décembre 2024 à 10:12:52

the openwrt just doesn't forward IGMP traffic, normally they have igmpproxy package for that but it require a clear LAN/WAN interface meanwhile the GPON stick doesn't really expose the L2 WAN interface to the openwrt OS so I have no idea how to make it work

Je n'ai pas trouvé ton post dans le thread, mais si le stick GPON n'expose pas une interface L2, qu'expose-t-il ? Le stick est bien connecté en SFP au routeur, qui est par définition une interface Ethernet. Le multicast fonctionne (sans quoi IPv6 ne fonctionnerait pas).
Ca ne serait pas simplement un problème de config d'igmpproxy ? Ou de firewall d'OpenWRT ?

Je n'ai pas de billes la dedans, je ne suis pas client SFR et n'ai pas le hardware en question, mais le commentaire a titillé ma curiosité