Auteur Sujet: La fibre Orange à 2Gbps, sur un routeur MikroTik 10Gbps CCR2004, via un ONT SFP+ (Lu 931249 fois)

stefbwz · « **Réponse #1452 le:** 05 mars 2021 à 23:03:29 »

Cool de plus être seul avec la macchiatobin.

Citation de: nitro le 05 mars 2021 à 20:26:32

Bon du coup j’ai commandé une macchiatobin single shot. Est-ce que quelqu’un l’a testé avec un MA5671A sur le port 2,5gb ?

j'en ai un qui n'est pas encore rooté, que j'avais pris au cas ou, mais je ne l'ai pas testé, car pour que ça marche il doit être en 05, c'est le moment ou le tx_fault n’empêche plus l'interface de monter.

L'autre truc avec le MA5671A par rapport au G-010S-{A,P}, c'est qu'il qu'il n'a pas d'eeprom i2c, et donc il met plus longtemps à s'initialiser et s'identifier cote sfp, car il doit booter et lancer lancer le daemon sfp_i2c qui émule la rom, et ça met du temps à démarrer.

Il semble qu'un patch soit inclus dans les versions snapshots, donc peut être que tu n'auras même pas besoin de recompiler openwrt : https://github.com/openwrt/openwrt/blob/master/target/linux/generic/backport-5.4/735-v5.5-net-sfp-allow-sfp-to-probe-slow-to-initialise-GPON-m.patch

De plus avec le firmware carlitov1, il y a des soucis de lecture de cette "EEPROM" par le driver sfp linux; ça ne me pose pas de souci avec le G-010S-P, car il dispose d'une eeprom, et donc le workaround est juste de déconnecter le sfp après un reboot.
C'est un petit souci que je compte bien régler, soit en repassant sous le firmware d'origine en le paramétrant correctement, soit en adaptant un patch qui fait déjà la même chose pour quelques sfp gpon à base de realtek.

Voici l'erreur lors d'un reboot a chaud avec le firmware carlitov1

Code: [Sélectionner]

[    9.235097] sfp sfp-eth3: EEPROM extended structure checksum failure: 0x77 != 0x63
[    9.242708] sfp EE: 00000000: 03 04 01 00 00 00 00 00 00 00 00 03 19 00 00 c8  ................
[    9.251444] sfp EE: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    9.260177] sfp EE: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    9.268912] sfp EE: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 01 14 00 01  ................
[    9.277653] sfp EE: 00000040: 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[    9.286388] sfp EE: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 68 f0 05 63  ............h..c
[    9.295125] sfp sfp-eth3: module   rev  sn  dc

Il semble que le carlitov2 ait le même genre de problème :

https://forum.turris.cz/t/ma5671a-sfp-issues-on-turris-os-5-0-3/13443/2

Aize147 · « **Réponse #1453 le:** 06 mars 2021 à 11:29:27 »

Je dois donc en conclure que par rapport aux réponses précédentes concernant le HardwareVersion ce n'est pas possible de le set correctement avec ritool.

stevebrush · « **Réponse #1454 le:** 06 mars 2021 à 13:00:34 »

Citation de: Aize147 le 06 mars 2021 à 11:29:27

Je dois donc en conclure que par rapport aux réponses précédentes concernant le HardwareVersion ce n'est pas possible de le set correctement avec ritool.

C’est ce que j’ai fait avec mon G-010S-A sur olt ALCL et ça fonctionne très bien.
Profil LB5 « installation neuve »
J’ai renseigné Mfrid, serial, hardwareversion avec ritool et hop ! Connection.

nonosch · « **Réponse #1455 le:** 06 mars 2021 à 13:58:47 »

Citation de: stevebrush le 06 mars 2021 à 13:00:34

C’est ce que j’ai fait avec mon G-010S-A sur olt ALCL et ça fonctionne très bien.
Profil LB5 « installation neuve »
J’ai renseigné Mfrid, serial, hardwareversion avec ritool et hop ! Connection.

Salut,

pour le serial et le hardwareversion il faut mettre en hexa tout le groupe SMBSxxxx ?

j'attends mon g-010s-A dans les prochains jours...

stevebrush · « **Réponse #1456 le:** 06 mars 2021 à 14:16:52 »

Citation de: nonosch le 06 mars 2021 à 13:58:47

Salut,

pour le serial et le hardwareversion il faut mettre en hexa tout le groupe SMBSxxxx ?

j'attends mon g-010s-A dans les prochains jours...

SMBS, c’est le MfrId, le serial, c’est juste les XXXXXXX après « SMBS » qui est déjà en hexa.
Le hardwareversion c’est celui de la LB5. Fais une recherche, j’ai déjà posté les valeurs et images.

nonosch · « **Réponse #1457 le:** 06 mars 2021 à 14:41:19 »

Citation de: stevebrush le 06 mars 2021 à 14:16:52

Fais une recherche, j’ai déjà posté les valeurs et images.

effectivement trouver au 17 janvier

merci de ton retour

JcDenis · « **Réponse #1458 le:** 06 mars 2021 à 17:56:35 »

Petit point du samedi

Je n'arrive à rien avec le G-010S-A, tellement que je pense que j'ai ruiné son soft

@proap tu risque d'avoir un gros colis bientôt

Quand au MA5671A je n'arrive toujours pas à monter en puissance.

Aujourd'hui j'ai testé Speedtest avec multi et single serveur et j'ai une différence de 300Mb aussi bien en Up qu'en Down mais inversé

Quelqu'un a une idée de si ça vient de ma config routeur ?

Multi :

Single :

Et sinon je suis repassé avec les drivers 2.5G direct sur Proxmox ce qui me permet de basculer de CHR à Pfsense ou autre un 15 secondes, bien pratique

nitro · « **Réponse #1459 le:** 06 mars 2021 à 22:56:21 »

A tout hasard, tu taggues bien tes paquets sortants en prio 1 ? si je le mets pas j'ai un upload catastrophique...

Citation de: JcDenis le 06 mars 2021 à 17:56:35

Petit point du samedi
Je n'arrive à rien avec le G-010S-A, tellement que je pense que j'ai ruiné son soft @proap tu risque d'avoir un gros colis bientôt
Quand au MA5671A je n'arrive toujours pas à monter en puissance.

Aujourd'hui j'ai testé Speedtest avec multi et single serveur et j'ai une différence de 300Mb aussi bien en Up qu'en Down mais inversé Quelqu'un a une idée de si ça vient de ma config routeur ?

Multi :

Single :

Et sinon je suis repassé avec les drivers 2.5G direct sur Proxmox ce qui me permet de basculer de CHR à Pfsense ou autre un 15 secondes, bien pratique

JcDenis · « **Réponse #1460 le:** 07 mars 2021 à 08:27:16 »

Citation de: nitro le 06 mars 2021 à 22:56:21

A tout hasard, tu taggues bien tes paquets sortants en prio 1 ? si je le mets pas j'ai un upload catastrophique...

Ah ? C'est à dire ? Je ne tague rien du tout $:-\$

nitro · « **Réponse #1461 le:** 07 mars 2021 à 12:17:17 »

Sous OpenBSD, si je ne mets pas cette regle, mon download est degrade mais surtout pour upload s'effondre...

Code: [Sélectionner]

match out on $wan_iface proto { tcp udp } set prio 1

Citation de: JcDenis le 07 mars 2021 à 08:27:16

Ah ? C'est à dire ? Je ne tague rien du tout $:-\$

stefbwz · « **Réponse #1462 le:** 07 mars 2021 à 12:27:37 »

Citation de: JcDenis le 07 mars 2021 à 08:27:16

Ah ? C'est à dire ? Je ne tague rien du tout $:-\$

Je dois aussi appliquer de la classification pour que ca marche correctement, sinon j'ai soit des pertes de débit, soit des ip privées reçues en dhcp, adapté depuis les intructions pour openwrt dans ce forum, le fichier vlanprio.sh

Code: [Sélectionner]

#!/bin/sh
set -x
for i in 0 1 2 3 4 5 6 7; do
    ip link set eth3.832 type vlan egress $i:$i >/dev/null  ## Chaque file devient en priorité $numdefile
    ip link set eth3.840 type vlan egress $i:5 >/dev/null   ## tout en prio 5 sur le vlan 840
done

ip link set eth3.832 type vlan egress 1:0 >/dev/null    ## La file (1) était donc en prio 1 on la repasse à 0, ça deviendra (via IPTABLES) la nouvelle file par défaut.
ip link set eth3.832 type vlan egress 0:6 >/dev/null    ## Tout le flux devient en prio 6 ! sauf le flux qui passera par IPTABLES (donc juste nos requêtes dhcp)

nitro · « **Réponse #1463 le:** 07 mars 2021 à 14:32:26 »

Bon du coup, vu que je veux du spare, je viens de prendre un G-010S-A et un P sur ebay, et je pourrai tester.
Par contre dans l'ideal, je vais tenter de faire tourner openbsd dessus, j'ai vu qu'un gars avait reussi, mais a des soucis avec les deux ports 10G.

Citation de: stefbwz le 05 mars 2021 à 23:03:29

Cool de plus être seul avec la macchiatobin.

j'en ai un qui n'est pas encore rooté, que j'avais pris au cas ou, mais je ne l'ai pas testé, car pour que ça marche il doit être en 05, c'est le moment ou le tx_fault n’empêche plus l'interface de monter.

L'autre truc avec le MA5671A par rapport au G-010S-{A,P}, c'est qu'il qu'il n'a pas d'eeprom i2c, et donc il met plus longtemps à s'initialiser et s'identifier cote sfp, car il doit booter et lancer lancer le daemon sfp_i2c qui émule la rom, et ça met du temps à démarrer.

Il semble qu'un patch soit inclus dans les versions snapshots, donc peut être que tu n'auras même pas besoin de recompiler openwrt : https://github.com/openwrt/openwrt/blob/master/target/linux/generic/backport-5.4/735-v5.5-net-sfp-allow-sfp-to-probe-slow-to-initialise-GPON-m.patch

De plus avec le firmware carlitov1, il y a des soucis de lecture de cette "EEPROM" par le driver sfp linux; ça ne me pose pas de souci avec le G-010S-P, car il dispose d'une eeprom, et donc le workaround est juste de déconnecter le sfp après un reboot.
C'est un petit souci que je compte bien régler, soit en repassant sous le firmware d'origine en le paramétrant correctement, soit en adaptant un patch qui fait déjà la même chose pour quelques sfp gpon à base de realtek.

Voici l'erreur lors d'un reboot a chaud avec le firmware carlitov1
Code: [Sélectionner]
[ 9.235097] sfp sfp-eth3: EEPROM extended structure checksum failure: 0x77 != 0x63 [ 9.242708] sfp EE: 00000000: 03 04 01 00 00 00 00 00 00 00 00 03 19 00 00 c8 ................ [ 9.251444] sfp EE: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 9.260177] sfp EE: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 9.268912] sfp EE: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 01 14 00 01 ................ [ 9.277653] sfp EE: 00000040: 00 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 9.286388] sfp EE: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 68 f0 05 63 ............h..c [ 9.295125] sfp sfp-eth3: module rev sn dc
Il semble que le carlitov2 ait le même genre de problème :

https://forum.turris.cz/t/ma5671a-sfp-issues-on-turris-os-5-0-3/13443/2