La Fibre
Forum : => La Fibre FTTH (Fiber To The Home) => 
Technologie Gpon / Le futur: XGS-PON et NG-PON2 => Discussion démarrée par: thinklad le 16 novembre 2024 à 15:41:21
-
Comme suggéré, je partage les infos que j'ai pour l'instant sur cet ONT XGS-PON dispo depuis relativement peu.
Ca pourrait être intéressant de faire un sujet (dans https://lafibre.info/gpon) pour discuter du LEOX (si tu as des photos du PCB, etc...).
Je vois très peu d'informations sur les RTL9615C / RTL9617C (rien sur hack-gpon par exemple), et comme j'ai indiqué sur https://lafibre.info/gpon/ont-xgs-pon-compatible/msg1094444/#msg1094444 les modèles chinois sont encore moins chers (à supposer que ce soit du Realtek, et pas encore d'autres SoC).
Page du constructeur: https://www.leolabs.pl/blog/ont-leox-lxe-010x-a.html
Chipset Realtek RTL9615C pour XGS-PON.
Prix en octobre 2024: 74,40 € + TVA + expédition → environ 120 €
Telnet leox/leolabs_7
GUI admin/letmein
À ma connaissance, personne n’a encore réussi à le faire fonctionner en bypass, du moins chez Orange.
Des photos de l’ONT et du PCB sont jointes à ce post, même si on ne distingue pas grand-chose à cause du dissipateur thermique et son interface.
(https://lafibre.info/images/materiel/202411_ont_xgs-pon_leolabs_leox_lxe-010x-a_1.avif)
(https://lafibre.info/images/materiel/202411_ont_xgs-pon_leolabs_leox_lxe-010x-a_2.avif)
(https://lafibre.info/images/materiel/202411_ont_xgs-pon_leolabs_leox_lxe-010x-a_3.avif)
(https://lafibre.info/images/materiel/202411_ont_xgs-pon_leolabs_leox_lxe-010x-a_4.avif)
-
Avec partie supérieure du boitier retirée :
(https://lafibre.info/images/materiel/202411_ont_xgs-pon_leolabs_leox_lxe-010x-a_5.avif)
-
PCB devissé, avec dissipateur thermique :
(https://lafibre.info/images/materiel/202411_ont_xgs-pon_leolabs_leox_lxe-010x-a_6.avif)
-
@thinklad et @fcueto : vous aviez des LXT-010H-D avant (également Realtek), ça pourrait être intéressant de comparer les MIBs.
Malheureusement l'OLT a peut-être été remplacé au moment du passage en XGS-PON, et je suppose que le SN de la LB7 n'est plus accepté en GPON.
@fcueto est sur OLT ALCL (omcicli mib get 131), @thinklad ?
Quand les VLAN sont listés côté OMCI, l'étape serait de regarder plus bas, pour voir si les flux GEM et les VLAN sont correctement configurés.
Est-ce qu'il y a une commande "diag" comme sur les RTL9601 (cf https://github.com/Anime4000/RTL960x/blob/main/Docs/DIAG.md) ?
Quelque chose qui m'avait aidé à voir un début de fonctionnel sur le G-010S-A (sur OLT HWTC), c'était :
- mettre l'adresse MAC de la Livebox sur le "routeur", et éventuellement l'IP aussi (pas sûr que ce soit nécessaire)
- passer la fibre de la Livebox vers l'ONT
- envoyer quelques paquets sur le VLAN 832, de sorte que l'adresse MAC soit connue de l'ONT (table de forward du bridge)
- capturer le traffic (Wireshark / tcpdump), et tenter de se connecter à l'IP publique depuis une autre connexion internet
Ca m'avait permis de voir que je pouvais recevoir des paquets (parce que les caches ARP étaient encores présents côté routeur Orange), mais que l'envoi ne fonctionnait pas (d'où l'absence de réponse au DHCP, et qu'au bout d'un certain temps je ne recevais plus rien parce que le routeur Orange ne recevait plus de réponses à ses requêtes ARP).
-
@thinklad et @fcueto : vous aviez des LXT-010H-D avant (également Realtek), ça pourrait être intéressant de comparer les MIBs.
Malheureusement l'OLT a peut-être été remplacé au moment du passage en XGS-PON, et je suppose que le SN de la LB7 n'est plus accepté en GPON.
En effet, plus d’accès GPON (j’avais essayé après activation LB7).
@fcueto est sur OLT ALCL (omcicli mib get 131), @thinklad ?
Idem.
Quand les VLAN sont listés côté OMCI, l'étape serait de regarder plus bas, pour voir si les flux GEM et les VLAN sont correctement configurés.
S’agit-il de la commande omcicli mib get 171? (J’ai fourni ça au support Leolabs mais n’ai pas eu de retour depuis quelques jours). Extrait ci-dessous si ça peut aider.
Est-ce qu'il y a une commande "diag" comme sur les RTL9601 (cf https://github.com/Anime4000/RTL960x/blob/main/Docs/DIAG.md) ?
Oui.
# omcicli mib get 171
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ExtVlanTagOperCfgData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityId: 0x101
AssociationType: 2
ReceivedFrameVlanTagOperTableMaxSize: 0
InputTPID: 0x8100
OutputTPID: 0x8100
DsMode: 0
ReceivedFrameVlanTaggingOperTable
INDEX 0
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 7,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 7,VID 852, TPID 2
INDEX 1
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 6,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 5,VID 852, TPID 2
…
AssociatedMePoint: 0x101
DscpToPbitMapping:
0x000000
0x249249
0x492492
0x6db6db
0x924924
0xb6db6d
0xdb6db6
0xffffff
Parsed DscpToPbitMapping:
dscp: 0 => pbit: 0
dscp: 1 => pbit: 0
…
-
Et avec dissipateur retiré :
(https://lafibre.info/images/materiel/202411_ont_xgs-pon_leolabs_leox_lxe-010x-a_7.avif)
-
Au cas où, un dump de la flash (25N02 sur le dessous du PCB) peut toujours servir.
Sur le Discord 8311, il y a un dump du AIWORKS AW-XGP12V aussi en Realtek (mais avec deux ports Ethernet, tout comme le AW-XGP12 (sans V) dont la photo correspond au VSOL V2902A).
Logiquement ça devrait être possible de lire les mtd depuis le telnet (s'il y a ssh c'est encore plus simple pour transférer) s'il y a un accès root (au cas où, "su" peut être suffisant, parfois root n'a pas de mot de passe et le login via telnet / ssh est juste désactivé).
Sinon via l'UART, il y a des chances que ça donne une console en root.
-
Au cas où, un dump de la flash (25N02 sur le dessous du PCB) peut toujours servir.
Sur le Discord 8311, il y a un dump du AIWORKS AW-XGP12V aussi en Realtek (mais avec deux ports Ethernet, tout comme le AW-XGP12 (sans V) dont la photo correspond au VSOL V2902A).
Logiquement ça devrait être possible de lire les mtd depuis le telnet (s'il y a ssh c'est encore plus simple pour transférer) s'il y a un accès root (au cas où, "su" peut être suffisant, parfois root n'a pas de mot de passe et le login via telnet / ssh est juste désactivé).
Sinon via l'UART, il y a des chances que ça donne une console en root.
Je viens d'essayer, pas de ssh ni de su possible a priori.
Par contre via telnet il y a un paquet de commandes possibles — est-ce que l'une d'entre elles te dirait quelque chose? (peut-être flash_otp_dump ou nanddump?
CMU_8.sh cpu_400.sh flash_lock less nc sed ubinfo
LD_disable.sh cpu_400_17cm.sh flash_otp_dump linuxrc netstat seq ubinize
PON_serdes_disable.sh create_cgroup_nas.sh flash_otp_info ln nic_limit_page.sh set_lan_disable.sh ubirename
PortMirror create_scfg_txt.sh flash_otp_lock loadconfig nice set_lan_ge_to_fe.sh ubirmvol
ShowStatus crond flash_otp_write login nologin setup_cgroup.sh ubirsvol
USB_disable.sh cups-lpd flash_unlock low_power.sh nslookup sh ubiupdatevol
addgroup cupsd flashcp lp ntfs-3g sleep udhcpc
adduser cut free lpadmin ntfslabel slogd udhcpc.deconfig
app-cli cwmpClient fsync lpstat nv slogd_sync.sh udhcpc.sh
ar date ftp ls oamcli smuxctl udhcpd
arp dd ftpd lsmod omci_app sntpd udpechoserver
arp_monitor delgroup fuser lxcli omci_debug.sh speed_test.sh umount
arpsend deluser fw_loaded.sh md5sum omcicli spppctl uname
ash depmod fwu_starter.sh mdev p2_all.sh spppd uncompress
awk devmem get_skb_mark memtester passwd startcupsd unzip
axel devpts.sh getopt mfcv6d pidof startup updatedd
backend/ df getty mib ping stat updateddctrl
basename dhclient grep mini_upnpd ping6 stty upnpctrl
bash dhcpd gunzip miniupnpd pondetect sync uptime
beep dhcrelayV6 gzip mkdir poweroff sysconf usbmount
blkid diag halt mkdosfs prlimit sysctl usleep
blkid2 diff hd mkexfatfs ps sysfs.sh vconfig
boa disableSlic_17c.sh head mkfs.vfat pwd systemd vendor_set
board_init.sh disableSlic_17cm.sh hexdump mknod qc tail vi
brctl disable_printk.sh hgu-show-temp.sh mkntfs radvd tar vm_tuning_g3hgu.sh
bridge dmesg hostapd mldproxy radvdump tc vsntp
busybox dnsmasq hostapd_cli modinfo ramonitor tcpdump wc
bzip2 ebtables id modprobe readlink telnet which
cat echo ifconfig modutils.sh readprofile telnetd wifi6_1T1R_disable.sh
checkpon egrep igmpproxy monitord reboot tftp wifi6_8192XBR_1T1R_disable_8832BR.sh
checkroot.sh eponoamd inetd more renice tftpd wifi6_8832BR_1T1R_disable_8192XBR.sh
chgrp ethctl init mount reset_default.sh top wifi6_config.sh
chmod ethtool ins_rtk_snooping_mod.sh mount.exfat restart_dnsrelay.sh touch wifi_modutils.sh
chown exfatfsck insmod mount_G3_UBIFS.sh rm tr wlan_led_set.sh
chpasswd exfatlabel ip mpctl rmmod tr142_app wlan_low_power.sh
chroot expr ip6tables mpctl_led_label_trigger.sh route traceroute wlan_stability_test_kill_process.sh
chvt factory_vlan100_l2_add ipset mtd_debug routed traceroute6 wpa_cli
clean_memory.sh fgconsole iptables mtdinfo rps.sh ubiattach wpa_supplicant
cmp fgrep iw mtdpart rtk_watchdog ubiblock xargs
config_ubifs_recovery.sh find kill mv rtkbosa ubicrc32 xtables-multi
configd flash killall nanddump rtkbosa.sh ubidetach zcat
consoleset flash_erase klogd nandtest rtl8277c_config ubiformat
cp flash_eraseall lan_recovery.sh nandwrite saveconfig ubimkvol
-
S’agit-il de la commande omcicli mib get 171? (J’ai fourni ça au support Leolabs mais n’ai pas eu de retour depuis quelques jours). Extrait ci-dessous si ça peut aider. Oui.
Je parlais plus des commandes diag pour voir plus bas si tout ce que le démon OMCI a accepté avait été appliqué.
Mais si je compare avec ce que @fcueto a (https://lafibre.info/remplacer-livebox/onu-compatible-xgs-pon-orange/msg1095154/#msg1095154 et https://lafibre.info/remplacer-livebox/onu-compatible-xgs-pon-orange/msg1094595/#msg1094595), je vois que bizarrement l'ordre n'est pas le même : il a le 835 en premier, pas le 851.
Pour le VLAN 832, qui est celui qui nous intéresse en priorité, il a :
INDEX 18
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 8,VID 832, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 8,VID 2800, TPID 2ce qui semble correct si on compare avec https://github.com/akhamar/orange-xgs-pon/blob/main/README.md.bak#L159
C'est associé à l'Ethernet UNI 0x101 :
AssociationType: 2
…
AssociatedMePoint: 0x101
Ca ne colle pas avec l'Ethernet UNI 0xa01 par défaut (ce qui indique que l'OLT pousse sa configuration sans avoir regardé quel port était exposé).
https://lafibre.info/remplacer-livebox/onu-compatible-xgs-pon-orange/msg1095154/#msg1095154 : @fcueto indique qu'il a reçu un firmware qui changeait en 0x101.
Mais on ne sait jamais, peut-être que le changement a uniquement affecté ce qui est exposé (omcicli mib get 11), mais pas le mapping dans l'autre sens (règle liée à 0x101 => appliquer sur le port Ethernet).
-
Je viens d'essayer, pas de ssh ni de su possible a priori.
Par contre via telnet il y a un paquet de commandes possibles — est-ce que l'une d'entre elles te dirait quelque chose? (peut-être flash_otp_dump ou nanddump?
Il n'y a pas de commandes spécifiques à avoir un cp ou dd fonctionne sur les /dev/mtdX.
Mais si l'utilisateur en telnet n'est pas root, alors normalement il n'aura pas le droit de lire.
On peut vérifier avec "id" et "ls -l /dev/mtd*".
-
Il n'y a pas de commandes spécifiques à avoir un cp ou dd fonctionne sur les /dev/mtdX.
Mais si l'utilisateur en telnet n'est pas root, alors normalement il n'aura pas le droit de lire.
On peut vérifier avec "id" et "ls -l /dev/mtd*".
A ma surprise, l'utilisateur est root et on voit donc ces fichiers:
# id
uid=0(root) gid=0(root) groups=0(root)
# ls -l /dev/mtd*
crw-rw---- 1 root root 90, 0 Jan 1 00:00 /dev/mtd0
crw-rw---- 1 root root 90, 1 Jan 1 00:00 /dev/mtd0ro
crw-rw---- 1 root root 90, 2 Jan 1 00:00 /dev/mtd1
crw-rw---- 1 root root 90, 20 Jan 1 00:00 /dev/mtd10
crw-rw---- 1 root root 90, 21 Jan 1 00:00 /dev/mtd10ro
crw-rw---- 1 root root 90, 22 Jan 1 00:00 /dev/mtd11
crw-rw---- 1 root root 90, 23 Jan 1 00:00 /dev/mtd11ro
crw-rw---- 1 root root 90, 24 Jan 1 00:00 /dev/mtd12
crw-rw---- 1 root root 90, 25 Jan 1 00:00 /dev/mtd12ro
crw-rw---- 1 root root 90, 26 Jan 1 00:00 /dev/mtd13
crw-rw---- 1 root root 90, 27 Jan 1 00:00 /dev/mtd13ro
crw-rw---- 1 root root 90, 28 Jan 1 00:00 /dev/mtd14
crw-rw---- 1 root root 90, 29 Jan 1 00:00 /dev/mtd14ro
crw-rw---- 1 root root 90, 3 Jan 1 00:00 /dev/mtd1ro
crw-rw---- 1 root root 90, 4 Jan 1 00:00 /dev/mtd2
crw-rw---- 1 root root 90, 5 Jan 1 00:00 /dev/mtd2ro
crw-rw---- 1 root root 90, 6 Jan 1 00:00 /dev/mtd3
crw-rw---- 1 root root 90, 7 Jan 1 00:00 /dev/mtd3ro
crw-rw---- 1 root root 90, 8 Jan 1 00:00 /dev/mtd4
crw-rw---- 1 root root 90, 9 Jan 1 00:00 /dev/mtd4ro
crw-rw---- 1 root root 90, 10 Jan 1 00:00 /dev/mtd5
crw-rw---- 1 root root 90, 11 Jan 1 00:00 /dev/mtd5ro
crw-rw---- 1 root root 90, 12 Jan 1 00:00 /dev/mtd6
crw-rw---- 1 root root 90, 13 Jan 1 00:00 /dev/mtd6ro
crw-rw---- 1 root root 90, 14 Jan 1 00:00 /dev/mtd7
crw-rw---- 1 root root 90, 15 Jan 1 00:00 /dev/mtd7ro
crw-rw---- 1 root root 90, 16 Jan 1 00:00 /dev/mtd8
crw-rw---- 1 root root 90, 17 Jan 1 00:00 /dev/mtd8ro
crw-rw---- 1 root root 90, 18 Jan 1 00:00 /dev/mtd9
crw-rw---- 1 root root 90, 19 Jan 1 00:00 /dev/mtd9ro
brw-rw---- 1 root root 31, 0 Jan 1 00:00 /dev/mtdblock0
brw-rw---- 1 root root 31, 1 Jan 1 00:00 /dev/mtdblock1
brw-rw---- 1 root root 31, 10 Jan 1 00:00 /dev/mtdblock10
brw-rw---- 1 root root 31, 11 Jan 1 00:00 /dev/mtdblock11
brw-rw---- 1 root root 31, 12 Jan 1 00:00 /dev/mtdblock12
brw-rw---- 1 root root 31, 13 Jan 1 00:00 /dev/mtdblock13
brw-rw---- 1 root root 31, 14 Jan 1 00:00 /dev/mtdblock14
brw-rw---- 1 root root 31, 2 Jan 1 00:00 /dev/mtdblock2
brw-rw---- 1 root root 31, 3 Jan 1 00:00 /dev/mtdblock3
brw-rw---- 1 root root 31, 4 Jan 1 00:00 /dev/mtdblock4
brw-rw---- 1 root root 31, 5 Jan 1 00:00 /dev/mtdblock5
brw-rw---- 1 root root 31, 6 Jan 1 00:00 /dev/mtdblock6
brw-rw---- 1 root root 31, 7 Jan 1 00:00 /dev/mtdblock7
brw-rw---- 1 root root 31, 8 Jan 1 00:00 /dev/mtdblock8
brw-rw---- 1 root root 31, 9 Jan 1 00:00 /dev/mtdblock9Lequel faudrait-il ? Tous ?
-
A ma surprise, l'utilisateur est root et on voit ces fichiers:
OK, donc soit il y a quelque chose de particulier au niveau du telnet, soit l'utilisateur "leox" est juste un alias (défini comme UID 0 dans /etc/passwd).
Lequel faudrait-il ? Tous ?
On peut utiliser les mtdX.
les mtdXro sont les mêmes en lecture seule, et les mtdblockX sont une ancienne émulation de mode bloc qui ne gère pas les blocs défectueux (donc ça peut passer sur une NOR, mais pas une NAND).
Mais en fait comme c'est une NAND il faut utiliser nanddump, et pas cp / dd.
Donc "nanddump -f /tmp/mtd0 /dev/mtd0" par exemple.
"cat /proc/mtd" donne les noms (boot, ...), il y a peut-être des mtd virtuelles (souvent les traces de boot, dmesg, en disent plus).
Il y a des chances pour que certaines mtd contiennent des volumes ubi ("ubinfo -a" pour vérifier), et dans ce cas on peut aussi copier (avec cp ou dd) les /dev/ubiX_Y).
-
C'est associé à l'Ethernet UNI 0x101 :
AssociationType: 2
…
AssociatedMePoint: 0x101
Ca ne colle pas avec l'Ethernet UNI 0xa01 par défaut (ce qui indique que l'OLT pousse sa configuration sans avoir regardé quel port était exposé).
https://lafibre.info/remplacer-livebox/onu-compatible-xgs-pon-orange/msg1095154/#msg1095154 : @fcueto indique qu'il a reçu un firmware qui changeait en 0x101.
Mais on ne sait jamais, peut-être que le changement a uniquement affecté ce qui est exposé (omcicli mib get 11), mais pas le mapping dans l'autre sens (règle liée à 0x101 => appliquer sur le port Ethernet).
Je ne suis pas sûr de la syntaxe, ni si ça va garder les règles, mais on pourrait tenter :
omcicli mib set 171 0x101 AssociatedMePoint 0xa01
On peut ensuite vérifier que les règles sont toujours là avec "omcicli mib get 171".
Ca ferait comme si l'OLT avait bien indiqué d'appliquer les règles au PPTP Ethernet UNI 0xa01, cad le port 10Gbps du Leox.
-
Infos supplémentaires sur CPU: comme suggéré ici (https://lafibre.info/remplacer-livebox/onu-compatible-xgs-pon-orange/msg1095224/#msg1095224), on semble bien être sur du Cortex A55 (0xd05).
cat /proc/cpuinfo
processor : 0
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
processor : 1
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x2
CPU part : 0xd05
CPU revision : 0
-
Mais en fait comme c'est une NAND il faut utiliser nanddump, et pas cp / dd.
Donc "nanddump -f /tmp/mtd0 /dev/mtd0" par exemple.
"cat /proc/mtd" donne les noms (boot, ...), il y a peut-être des mtd virtuelles (souvent les traces de boot, dmesg, en disent plus).
Il y a des chances pour que certaines mtd contiennent des volumes ubi ("ubinfo -a" pour vérifier), et dans ce cas on peut aussi copier (avec cp ou dd) les /dev/ubiX_Y).
Merci pour les précisions !
On voit effectivement que de mtd4 à mtd14 c'est ubi:
cat /proc/mtd
dev: size erasesize name
mtd0: 00200000 00020000 "boot"
mtd1: 00040000 00020000 "env"
mtd2: 00040000 00020000 "env2"
mtd3: 00040000 00020000 "static_conf"
mtd4: 0f5c0000 00020000 "ubi_device"
mtd5: 00a0d000 0001f000 "ubi_Config"
mtd6: 0005d000 0001f000 "ubi_DTB0"
mtd7: 0060e000 0001f000 "ubi_k0"
mtd8: 01911000 0001f000 "ubi_r0"
mtd9: 0005d000 0001f000 "ubi_DTB1"
mtd10: 0060e000 0001f000 "ubi_k1"
mtd11: 01911000 0001f000 "ubi_r1"
mtd12: 0081d000 0001f000 "ubi_framework1"
mtd13: 0081d000 0001f000 "ubi_framework2"
mtd14: 03013000 0001f000 "ubi_apps"Je récupère tout ça.
-
J'ai pu tout récupérer, à l'exception de mtd5. (Je te PM avec un lien pour le dump).
dd if=/dev/mtd5 of=/tmp/mtd5_dump.bin
dd: can't open '/dev/mtd5': Device or resource busyIdem avec nanddump
nanddump -o /dev/mtd5 > /tmp/mtd5_dump.bin
/dev/mtd5: Device or resource busy
ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:62
Present UBI devices: ubi0
ubi0
Volumes count: 10
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 1966 (249634816 bytes, 238.1 MiB)
Amount of available logical eraseblocks: 788 (100057088 bytes, 95.4 MiB)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 40
Current maximum erase counter value: 2
Minimum input/output unit size: 2048 bytes
Character device major/minor: 250:0
Present volumes: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 83 LEBs (10539008 bytes, 10.1 MiB)
State: OK
Name: ubi_Config
Character device major/minor: 250:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 3 LEBs (380928 bytes, 372.0 KiB)
State: OK
Name: ubi_DTB0
Character device major/minor: 250:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 50 LEBs (6348800 bytes, 6.1 MiB)
State: OK
Name: ubi_k0
Character device major/minor: 250:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 207 LEBs (26284032 bytes, 25.1 MiB)
State: OK
Name: ubi_r0
Character device major/minor: 250:4
-----------------------------------
Volume ID: 4 (on ubi0)
Type: dynamic
Alignment: 1
Size: 3 LEBs (380928 bytes, 372.0 KiB)
State: OK
Name: ubi_DTB1
Character device major/minor: 250:5
-----------------------------------
Volume ID: 5 (on ubi0)
Type: dynamic
Alignment: 1
Size: 50 LEBs (6348800 bytes, 6.1 MiB)
State: OK
Name: ubi_k1
Character device major/minor: 250:6
-----------------------------------
Volume ID: 6 (on ubi0)
Type: dynamic
Alignment: 1
Size: 207 LEBs (26284032 bytes, 25.1 MiB)
State: OK
Name: ubi_r1
Character device major/minor: 250:7
-----------------------------------
Volume ID: 7 (on ubi0)
Type: dynamic
Alignment: 1
Size: 67 LEBs (8507392 bytes, 8.1 MiB)
State: OK
Name: ubi_framework1
Character device major/minor: 250:8
-----------------------------------
Volume ID: 8 (on ubi0)
Type: dynamic
Alignment: 1
Size: 67 LEBs (8507392 bytes, 8.1 MiB)
State: OK
Name: ubi_framework2
Character device major/minor: 250:9
-----------------------------------
Volume ID: 9 (on ubi0)
Type: dynamic
Alignment: 1
Size: 397 LEBs (50409472 bytes, 48.1 MiB)
State: OK
Name: ubi_apps
Character device major/minor: 250:10
-
Pour info, les commandes dispos via diag:
RTK.0>
acl - acl configuration
bandwidth - bandwidth configuration
classf - classification configuration
cpu - cpu configuration
debug - debug configuration
dot1x - dot1x configuration
epon - epon configuration
exit - exit diag shell
field-selector - field selector configuration
flowctrl - flowctrl configuration
gpon - GPON configuration
i2c - I2C configuration
igmp - igmp configuration
interrupt - interrupt configuration
iol - iol configuration
l2-table - l2 table configuration
led - led configuration
meter - shared meter configuration
mib - mib configuration
mirror - mirror configuration
oam - oam configuration
pbo - pbo configuration
pon - pon configuration
port - port configuration
ppstod - ppstod configuration
qos - qos configuration
register - register configuration
rldp - rldp configuration
rlpp - RLPP configuration
rma - rma configuration
rt_acl - rt_acl configuration
rt_cls - cls configuration
rt_epon - rt_epon configuration
rt_flow - rt_flow configuration
rt_gpon - GPON configuration
rt_i2c - I2C configuration
rt_igmp - rt_igmp configuration
rt_interrupt - rt_interrupt configuration
rt_l2-table - rt_l2 table configuration
rt_mdio - MDIO configuration
rt_mib - rt_mib configuration
rt_mirror - mirror configuration
rt_misc - rt_misc configuration
rt_oam - rt_oam configuration
rt_pe - rt_pe configuration
rt_ponmisc - rt_ponmisc table configuration
rt_port - rt_port configuration
rt_qos - rt_qos configuration
rt_rate - rt_rate configuration
rt_security - rt_security configuration
rt_switch - rt_switch configuration
rt_time - rt_time configuration
rt_trap - rt_trap configuration
security - security configuration
storm-control - storm-control configuration
stp - stp configuration
svlan - svlan configuration
switch - switch configuration
swpbo - switch pbo configuration
time - time configuration
trap - trap configuration
trunk - trunk configuration
vlan - vlan configuration
-
Merci pour les précisions !
On voit effectivement que de mtd4 à mtd14 c'est ubi:
cat /proc/mtd
dev: size erasesize name
mtd0: 00200000 00020000 "boot"
mtd1: 00040000 00020000 "env"
mtd2: 00040000 00020000 "env2"
mtd3: 00040000 00020000 "static_conf"
mtd4: 0f5c0000 00020000 "ubi_device"
mtd5: 00a0d000 0001f000 "ubi_Config"
mtd6: 0005d000 0001f000 "ubi_DTB0"
mtd7: 0060e000 0001f000 "ubi_k0"
mtd8: 01911000 0001f000 "ubi_r0"
mtd9: 0005d000 0001f000 "ubi_DTB1"
mtd10: 0060e000 0001f000 "ubi_k1"
mtd11: 01911000 0001f000 "ubi_r1"
mtd12: 0081d000 0001f000 "ubi_framework1"
mtd13: 0081d000 0001f000 "ubi_framework2"
mtd14: 03013000 0001f000 "ubi_apps"Je récupère tout ça.
Donc il a 5 vraies partitions mtd :
- boot : table de partition GPT, contenant deux partitions fip0 / fip1 (chacune contient BL2 + U-Boot), donc même les mises à jour semblent prévues ici (mais ça ne m'étonnerait pas que ce soit signé)
- env / env2 : variables d'environnement U-Boot
- static_conf : vide
- ubi_device : ubi
mtd4 est montée en ubi, et les volumes qui sont dedans sont également exposés en tant que mtd virtuelle.
Selon les usages, le montage ou la lecture peut se faire avec l'une ou l'autre (l'écriture pour les mises à jour doit passer par ubi, et bien sûr dtb et kernels sont lus par le bootloader).
En tout cas dans la forme ça ressemble au dump du AW-XGP12V, mais :
- avec boot plus petit
- peut-être avec plus de partitions UBI : le dump partagé sur Discord a DTB0 / k0 / r0 uniquement
Sinon, le SoC semble s'appeler Taurus, et (malheureusement ?) il y a beaucoup de références à Cortina (contrôleur NAND SPI, UART, GPIO, I2C).
-
Infos complémentaires sur VLAN :
omcicli mib get 84
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VlanTagFilterData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityID: 0x1102
FilterTbl[0]: PRI 0,CFI 0, VID 2800
FwdOp: 0x10
NumOfEntries: 1
=================================
=================================
EntityID: 0x1103
FilterTbl[0]: PRI 0,CFI 0, VID 835
FwdOp: 0x10
NumOfEntries: 1
=================================
=================================
EntityID: 0x1104
FilterTbl[0]: PRI 0,CFI 0, VID 852
FwdOp: 0x10
NumOfEntries: 1
=================================
=================================
EntityID: 0x110b
FilterTbl[0]: PRI 0,CFI 0, VID 835
FilterTbl[2]: PRI 0,CFI 0, VID 852
FilterTbl[4]: PRI 0,CFI 0, VID 2800
FwdOp: 0x10
NumOfEntries: 3
=================================
omcicli mib get 171
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ExtVlanTagOperCfgData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityId: 0x101
AssociationType: 2
ReceivedFrameVlanTagOperTableMaxSize: 0
InputTPID: 0x8100
OutputTPID: 0x8100
DsMode: 0
ReceivedFrameVlanTaggingOperTable
INDEX 0
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 7,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 7,VID 852, TPID 2
INDEX 1
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 6,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 5,VID 852, TPID 2
INDEX 2
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 5,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 4,VID 852, TPID 2
INDEX 3
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 4,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 4,VID 852, TPID 2
INDEX 4
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 3,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 3,VID 852, TPID 2
INDEX 5
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 2,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 2,VID 852, TPID 2
INDEX 6
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 1,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 1,VID 852, TPID 2
INDEX 7
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 0,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 0,VID 852, TPID 2
INDEX 8
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 8,VID 835, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 8,VID 835, TPID 2
INDEX 9
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 8,VID 832, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 8,VID 2800, TPID 2
INDEX 10
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 15,VID 0, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 3
Treatment Inner : PRI 15,VID 0, TPID 2
INDEX 11
Filter Outer : PRI 14,VID 4096, TPID 5
Filter Inner : PRI 14,VID 4096, TPID 0, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 3
Treatment Inner : PRI 15,VID 4096, TPID 3
INDEX 12
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 14,VID 4096, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 3
Treatment Inner : PRI 15,VID 4096, TPID 2
AssociatedMePoint: 0xa01
DscpToPbitMapping:
0x000000
0x249249
0x492492
0x6db6db
0x924924
0xb6db6d
0xdb6db6
0xffffff
Parsed DscpToPbitMapping:
dscp: 0 => pbit: 0
dscp: 1 => pbit: 0
dscp: 2 => pbit: 0
dscp: 3 => pbit: 0
dscp: 4 => pbit: 0
dscp: 5 => pbit: 0
dscp: 6 => pbit: 0
dscp: 7 => pbit: 0
dscp: 8 => pbit: 1
dscp: 9 => pbit: 1
dscp: 10 => pbit: 1
dscp: 11 => pbit: 1
dscp: 12 => pbit: 1
dscp: 13 => pbit: 1
dscp: 14 => pbit: 1
dscp: 15 => pbit: 1
dscp: 16 => pbit: 2
dscp: 17 => pbit: 2
dscp: 18 => pbit: 2
dscp: 19 => pbit: 2
dscp: 20 => pbit: 2
dscp: 21 => pbit: 2
dscp: 22 => pbit: 2
dscp: 23 => pbit: 2
dscp: 24 => pbit: 3
dscp: 25 => pbit: 3
dscp: 26 => pbit: 3
dscp: 27 => pbit: 3
dscp: 28 => pbit: 3
dscp: 29 => pbit: 3
dscp: 30 => pbit: 3
dscp: 31 => pbit: 3
dscp: 32 => pbit: 4
dscp: 33 => pbit: 4
dscp: 34 => pbit: 4
dscp: 35 => pbit: 4
dscp: 36 => pbit: 4
dscp: 37 => pbit: 4
dscp: 38 => pbit: 4
dscp: 39 => pbit: 4
dscp: 40 => pbit: 5
dscp: 41 => pbit: 5
dscp: 42 => pbit: 5
dscp: 43 => pbit: 5
dscp: 44 => pbit: 5
dscp: 45 => pbit: 5
dscp: 46 => pbit: 5
dscp: 47 => pbit: 5
dscp: 48 => pbit: 6
dscp: 49 => pbit: 6
dscp: 50 => pbit: 6
dscp: 51 => pbit: 6
dscp: 52 => pbit: 6
dscp: 53 => pbit: 6
dscp: 54 => pbit: 6
dscp: 55 => pbit: 6
dscp: 56 => pbit: 7
dscp: 57 => pbit: 7
dscp: 58 => pbit: 7
dscp: 59 => pbit: 7
dscp: 60 => pbit: 7
dscp: 61 => pbit: 7
dscp: 62 => pbit: 7
dscp: 63 => pbit: 7
=================================
diag
RTK.0> vlan get vlan-table vid 832
Vid:832
Hash
IVL
member port : none
tag member port : 0-7,16-23
Mais quelque chose que je ne suis pas sur de saisir : est-ce que cette entrée ne veut pas dire que VLAN 832 est modifié pour VLAN 2800 ?
INDEX 9
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 8,VID 832, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 8,VID 2800, TPID 2
-
Je vois "AssociatedMePoint: 0xa01", donc c'est après avoir appliqué la commande ?
Si oui, il est peut-être initialement de comparer que qu'on peut voir dans diag (port, vlan, l2-tables, et éventuellement les mêmes avec le préfixe rt-).
Et ça ne fonctionne toujours pas ?
Pour ce qui est du VLAN 2800, il semble que ce soit utilisé côté réseau Orange dans certaines configurations.
cf https://lafibre.info/remplacer-livebox/mise-en-route-leox-lxt-010h-d/msg1092359/#msg1092359
Si jamais, à cause d'un bug ou d'une configuration particulière, le Leox est en 1:1, il faudrait alors tester le VLAN 2800 côté routeur.
-
Je vois "AssociatedMePoint: 0xa01", donc c'est après avoir appliqué la commande ?
Si oui, il est peut-être initialement de comparer que qu'on peut voir dans diag (port, vlan, l2-tables, et éventuellement les mêmes avec le préfixe rt-).
Et ça ne fonctionne toujours pas ?
Exact. En revenant sur omcicli mib set 171 0x101 AssociatedMePoint 0x101 :
omcicli mib get 84
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VlanTagFilterData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityID: 0x1102
FilterTbl[0]: PRI 0,CFI 0, VID 2800
FwdOp: 0x10
NumOfEntries: 1
=================================
=================================
EntityID: 0x1103
FilterTbl[0]: PRI 0,CFI 0, VID 835
FwdOp: 0x10
NumOfEntries: 1
=================================
=================================
EntityID: 0x1104
FilterTbl[0]: PRI 0,CFI 0, VID 852
FwdOp: 0x10
NumOfEntries: 1
=================================
=================================
EntityID: 0x110b
FilterTbl[0]: PRI 0,CFI 0, VID 835
FilterTbl[2]: PRI 0,CFI 0, VID 852
FilterTbl[4]: PRI 0,CFI 0, VID 2800
FwdOp: 0x10
NumOfEntries: 3
=================================
omcicli mib get 171
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ExtVlanTagOperCfgData
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityId: 0x101
AssociationType: 2
ReceivedFrameVlanTagOperTableMaxSize: 0
InputTPID: 0x8100
OutputTPID: 0x8100
DsMode: 0
ReceivedFrameVlanTaggingOperTable
INDEX 0
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 7,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 7,VID 852, TPID 2
INDEX 1
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 6,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 5,VID 852, TPID 2
INDEX 2
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 5,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 4,VID 852, TPID 2
INDEX 3
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 4,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 4,VID 852, TPID 2
INDEX 4
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 3,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 3,VID 852, TPID 2
INDEX 5
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 2,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 2,VID 852, TPID 2
INDEX 6
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 1,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 1,VID 852, TPID 2
INDEX 7
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 0,VID 851, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 0,VID 852, TPID 2
INDEX 8
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 8,VID 835, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 8,VID 835, TPID 2
INDEX 9
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 8,VID 832, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 1
Treatment Inner : PRI 8,VID 2800, TPID 2
INDEX 10
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 15,VID 0, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 3
Treatment Inner : PRI 15,VID 0, TPID 2
INDEX 11
Filter Outer : PRI 14,VID 4096, TPID 5
Filter Inner : PRI 14,VID 4096, TPID 0, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 3
Treatment Inner : PRI 15,VID 4096, TPID 3
INDEX 12
Filter Outer : PRI 15,VID 4096, TPID 0
Filter Inner : PRI 14,VID 4096, TPID 5, EthType 0x00
Treatment Outer : PRI 15,VID 0, TPID 0, RemoveTags 3
Treatment Inner : PRI 15,VID 4096, TPID 2
AssociatedMePoint: 0x101
DscpToPbitMapping:
0x000000
0x249249
0x492492
0x6db6db
0x924924
0xb6db6d
0xdb6db6
0xffffff
Parsed DscpToPbitMapping:
dscp: 0 => pbit: 0
dscp: 1 => pbit: 0
dscp: 2 => pbit: 0
dscp: 3 => pbit: 0
dscp: 4 => pbit: 0
dscp: 5 => pbit: 0
dscp: 6 => pbit: 0
dscp: 7 => pbit: 0
dscp: 8 => pbit: 1
dscp: 9 => pbit: 1
dscp: 10 => pbit: 1
dscp: 11 => pbit: 1
dscp: 12 => pbit: 1
dscp: 13 => pbit: 1
dscp: 14 => pbit: 1
dscp: 15 => pbit: 1
dscp: 16 => pbit: 2
dscp: 17 => pbit: 2
dscp: 18 => pbit: 2
dscp: 19 => pbit: 2
dscp: 20 => pbit: 2
dscp: 21 => pbit: 2
dscp: 22 => pbit: 2
dscp: 23 => pbit: 2
dscp: 24 => pbit: 3
dscp: 25 => pbit: 3
dscp: 26 => pbit: 3
dscp: 27 => pbit: 3
dscp: 28 => pbit: 3
dscp: 29 => pbit: 3
dscp: 30 => pbit: 3
dscp: 31 => pbit: 3
dscp: 32 => pbit: 4
dscp: 33 => pbit: 4
dscp: 34 => pbit: 4
dscp: 35 => pbit: 4
dscp: 36 => pbit: 4
dscp: 37 => pbit: 4
dscp: 38 => pbit: 4
dscp: 39 => pbit: 4
dscp: 40 => pbit: 5
dscp: 41 => pbit: 5
dscp: 42 => pbit: 5
dscp: 43 => pbit: 5
dscp: 44 => pbit: 5
dscp: 45 => pbit: 5
dscp: 46 => pbit: 5
dscp: 47 => pbit: 5
dscp: 48 => pbit: 6
dscp: 49 => pbit: 6
dscp: 50 => pbit: 6
dscp: 51 => pbit: 6
dscp: 52 => pbit: 6
dscp: 53 => pbit: 6
dscp: 54 => pbit: 6
dscp: 55 => pbit: 6
dscp: 56 => pbit: 7
dscp: 57 => pbit: 7
dscp: 58 => pbit: 7
dscp: 59 => pbit: 7
dscp: 60 => pbit: 7
dscp: 61 => pbit: 7
dscp: 62 => pbit: 7
dscp: 63 => pbit: 7
=================================diag
RTK.0> vlan get vlan-table vid 832
Vid:832
Hash
IVL
member port : none
tag member port : 0-7,16-23
RTK.0> vlan get vlan-table vid 2800
Vid:2800
Hash
IVL
member port : none
tag member port : 0-7,16-23
port get status port all
Port Status Speed Duplex TX_FC RX_FC
---- ------ ----- ------ ----- -----
0 Down 10M Half Dis Dis
1 Down 10M Half Dis Dis
2 Down 10M Half Dis Dis
3 Down 10M Half Dis Dis
4 Down 1000M Full Dis Dis
5 Up 10M Half Dis Dis
6 Up 10G Full Dis Dis
7 Down 1000M Full Dis Dis
Pour ce qui est du VLAN 2800, il semble que ce soit utilisé côté réseau Orange dans certaines configurations.
cf https://lafibre.info/remplacer-livebox/mise-en-route-leox-lxt-010h-d/msg1092359/#msg1092359
Si jamais, à cause d'un bug ou d'une configuration particulière, le Leox est en 1:1, il faudrait alors tester le VLAN 2800 côté routeur.
J'avais déjà tenté VLAN 2800 côté routeur mais ça ne marchait pas plus (j'ai répété à l'instant pour être sur).
Je ne saisis pas la différence entre les commandes diag avec ou sans rt, mais c'est étrange (port 6 : 1000M vs. 10G) :
RTK.0> rt_port get status port all
Port Status Speed Duplex TX_FC RX_FC
---- ------ ----- ------ ----- -----
0 Down 10M Half Dis Dis
1 Down 10M Half Dis Dis
2 Down 10M Half Dis Dis
3 Down 10M Half Dis Dis
4 Down 10M Half Dis Dis
5 Up 10M Half Dis Dis
6 Up 1000M Full Dis Dis
7 Down 1000M Full Dis Dis
RTK.0> port get status port all
Port Status Speed Duplex TX_FC RX_FC
---- ------ ----- ------ ----- -----
0 Down 10M Half Dis Dis
1 Down 10M Half Dis Dis
2 Down 10M Half Dis Dis
3 Down 10M Half Dis Dis
4 Down 1000M Full Dis Dis
5 Up 10M Half Dis Dis
6 Up 10G Full Dis Dis
7 Down 1000M Full Dis Dis
-
Donc la commande omcicli n'a pas l'air de changer quelque chose côté diag.
On pourrait éventuellement essayer de modifier le contenu, voire supprimer l'entité du mib 171 pour demander explicitement d'être en 1:1 (à voir pour les opérations sur les priorités).
Mais avant il y a peut-être "MAC Bridge Service Profile" (ME #45) et "MAC Bridge Port Configuration Data" (ME #47).
Dans le second, l'entité 0x101 a :
- BridgeIdPtr: 0x0101 => référence au 0x101 du premier, sauf que dans celui-ci le premier octet correspond au numéro de slot
- TPType: 1 => PPTP UNI
- TPPointer: 0x0101 => c'est un pointeur vers le PPTP UNI
=> il faudrait peut-être :
- toujours "omcicli mib set 171 0x101 AssociatedMePoint 0xa01"
- créer une entité 0xa01 dans le mib 45 (au lieu / en plus de 0x101)
- "omcicli mib set 47 0x101 TPPointer 0xa01 BridgeIdPtr 0xa01" (ou en deux commandes si on ne peut pas modifier les deux d'un coup)
Je suppose que le firmware qu'a eu @fcueto a l'approche inverse : si le PPTP UNI est bien 0x101 (ce qu'on pourrait aussi modifier, mais avant de brancher la fibre je pense, pour que ce soit avant l'ajout des règles qui vont le référencer), alors pas besoin de modifier ce que l'OLT ajoute.
Sauf que son firmware ne fonctionne pas non plus, donc peut-être que l'ONU ne fait pas le lien entre 0x101 et le port Ethernet, ou qu'il a un autre problème (il a plus de VLAN, avec la règle 832 vers la fin, donc pourrait tomber dans un bug type Cortina).
Sinon côté bas niveau :
Il y a deux ports up, ça pourrait être le port 10Gbps d'un côté, et le port interne vers le PON de l'autre.
Mais du coup il y a aurait une erreur sur la vitesse indiquée.
Les deux sont dans "tag member port", mais pour à la fois 832 et 2800.
J'aurais plus attendu 832 pour un port, et 2800 pour l'autre.
En tout cas la présence du 832 semble quand même indiquer un traitement du mib 171, parce qu'il n'est pas mentionné ailleurs.
Il y a aussi "l2-table get entry", mais là c'est plus difficile à comprendre.
Eventuellement "l2-table get vid-unmatch port all", pour voir ce qu'il advient des VLAN "inconnus".
-
J'avais oublié qu'en 2022 j'avais trouvé la config PORT_REMAPPING sur le V2802RH de @Fluor (Bouygues) :-[
C'est un RTL9601D, mais avec un RTOS au lieu de Linux (contrairement à ce qui est indiqué sur hack-gpon, dont soit il y a plusieurs sous-modèles, soit ils sont passés à Linux sur les firmwares plus récents malgré la NOR de 4Mo au lieu des 16Mo habituels).
Sur cette cible c'était simple :
- 0100000000000000 => port LAN1 fonctionnel
- 0001000000000000 => port LAN2 fonctionnel
Donc la position semblait correspondre au port Ethernet, et peut-être que le numéro correspondait au port (ou slot ?) OMCI.
Avec le RTL9615C ça semble plus compliqué :
- LXE-010X-A (port 10Gbps en 0xa01) :
- /etc/config_default_hs.xml (valeur par défault) : 06,00,00,00,00,00,00,00
- config_hs.xml dans ubi_Config de @thinklad : 06,00,00,00,00,00,00,00,2d,41,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
- AW-XGP12V (port 1Gbps en 0x101, port 10Gbps en 0x102) :
- /etc/config_default_hs.xml 00,06,-1,-1,-1,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
- config_hs.xml 00,06,00,00,00,00,00,00,f0,4f,51,e1,7f,00,00,00,08,62,b5,74,55,00,00,00,78,a4,b5,74,00,00,00,00
Ici 06 correspond au port 10Gbps, et 00 au port 1Gbps (du AW-XGP12V).
Avec "cat /proc/eth_nic/dev_port_mapping", on voit qu'il assigne la première valeur à eth0.2, et la seconde à eth0.3 (le reste est plus bizarre).
-
J'ai trouvé les configs qui devraient permettre de passer en PPTP UNI 0x101, à voir.
Le Leox a à priori un "/proc/realtek/uni_capability" avec "0;0;0;0;0;0;5" (valeur par défaut dans le kernel) à la fois pour "port capability" et "OMCI claim port capability".
"5" c'est pour 10Gbps, mais dans le démon OMCI ça correspond au slot 0xa.
Le AW-XGP12V a "port capability" a "2;0;0;0;0;0;2" : il déclare son port 1Gbps et son port 10Gps comme de type "2".
"2" c'est normalement pour 1Gbps, et dans le démon OMCI ça correspond au slot 0x1.
Donc à essayer avec la fibre débranchée (initialement) :
echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability
killall omci_app
...
omcicli mib get 11
-
Donc à essayer avec la fibre débranchée (initialement) :
echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability
killall omci_app
...
omcicli mib get 11
# omcicli mib get 11
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
EthUni
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityID: 0x0a01
ExpectedType: 49
SensedType: 49
AutoDectectCfg: 0
EthLoopbackCfg: 0
AdminState: 0
OpState: 0
DuplexInd: 3
MaxFrameSize: 1518
DTEorDCEInd: 0
PauseTime: 0
BridgedorIPInd: 2
ARC: 0
ARCInterval: 0
PppoeFilter: 0
PowerControl: 0
PhysicalPortId: 6
=================================
# echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability
# killall omci_app
# omcicli mib get 11
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
EthUni
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityID: 0x0101
ExpectedType: 47
SensedType: 47
AutoDectectCfg: 0
EthLoopbackCfg: 0
AdminState: 0
OpState: 0
DuplexInd: 3
MaxFrameSize: 1518
DTEorDCEInd: 0
PauseTime: 0
BridgedorIPInd: 2
ARC: 0
ARCInterval: 0
PppoeFilter: 0
PowerControl: 0
PhysicalPortId: 6
=================================
-
Maintenant avec ça les règles de VLAN poussées par l'OLT devraient bien correspondre avec l'instance PPTP UNI, et donc avec le port Ethernet de l'ONT.
Donc tu peux tester avec la fibre.
Selon la config (VLAN_CFG_TYPE / VLAN_MANU_MODE ?), tu pourrais être en mode transparent, donc si le VLAN 832 ne fonctionne pas il faudrait tester avec le VLAN 2800.
Selon @djGrrr sur le Discord 8311, le RTL9615C supporte bien le mapping de VLAN (alors qu'il y a un doute avec certains RTL960x comme le LXT-010H-D).
-
Maintenant avec ça les règles de VLAN poussées par l'OLT devraient bien correspondre avec l'instance PPTP UNI, et donc avec le port Ethernet de l'ONT.
Donc tu peux tester avec la fibre.
Ça marche ! (avec VLAN 832 côté routeur)
Et j'ai vérifié, pas de persistence après reboot ONT (j'imagine que pour ca, Leox devra faire une nouvelle version de firmware).
Note: le plafonnement en débit montant est lié à un bogue présumé du routeur avec la cage SFP (en cours d'investigation Ubiquiti).
-
Ça marche ! (avec VLAN 832 côté routeur)
8)
Maintenant il faut peut-être comprendre si c'est "mieux fait" que le firmware modifié que le support Leox a donné à @fcueto, ou s'il a un autre problème (il a plus de VLAN, et dans un ordre différent).
Et j'ai vérifié, pas de persistence après reboot ONT (j'imagine que pour ca, Leox devra faire une nouvelle version de firmware).
Tu peux éditer /var/config/run_customized_sdk.sh :
#!/bin/sh
echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability
Le script (vide par défaut, donc sans shebang...) est lancé par /etc/runsdk.sh juste avant le /etc/runomci.sh.
-
Marcin m'a envoyé le même firmware (V4.2.4L6a2) qu'il a envoyé a @fcueto et ça marche aussi pour moi (testé à l'instant).
Je n'ai pas l'option TV de mon côté, ça explique peut-être la différence de résultat ?
-
Marcin m'a envoyé le même firmware (V4.2.4L6a2) qu'il a envoyé a @fcueto et ça marche aussi pour moi (testé à l'instant).
Qu'est-ce qu'il y a comme /proc/realtek/uni_capability ?
Je n'ai pas l'option TV de mon côté, ça explique peut-être la différence de résultat ?
Si vous avez les mêmes paramètres par ailleurs, ça pourrait être ça.
Dans ce cas il faudra que @fcueto tente soit de modifier la liste des VLAN manuellement (mibs 84 et 171), soit de passer en mode transparent.
-
Qu'est-ce qu'il y a comme /proc/realtek/uni_capability ?
cat /proc/realtek/uni_capability
# port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;2
# OMCI claim port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;5
# logical port to physical port remapping
# -1: invalid port
6;-1;-1;-1;-1;-1;-1;-1
-
Donc c'est soit la commande intégrée dans un script quelque part, soit le kernel recompilé avec une option de config différente, soit peut-être une entrée ajoutée dans ma device-tree.
-
cat /proc/realtek/uni_capability
# port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;2
# OMCI claim port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;5
# logical port to physical port remapping
# -1: invalid port
6;-1;-1;-1;-1;-1;-1;-1
Je reviens là-dessus car la mise à jour du firmware ne s'était pas passée (j'avais oublié de remettre HW_HWVER sur LXE-010X-A, donc malgré les indication d'upload du FW et du redémarrage, ça tournait toujours sur le FW d'avant).
Après avoir refait la mise à jour comme il faut pour être sur V4.2.4L6a2, ça ne marche plus :
# cat /proc/realtek/uni_capability
# port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;5
# OMCI claim port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;5
# logical port to physical port remapping
# -1: invalid port
6;-1;-1;-1;-1;-1;-1;-1Après avoir refait la même manip que la dernière fois avec le firmware V4.2.4L5, je n'arrive plus à me connecter.
# echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability
# killall omci_app
# cat /proc/realtek/uni_capability
# port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;2
# OMCI claim port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;5
# logical port to physical port remapping
# -1: invalid port
6;-1;-1;-1;-1;-1;-1;-1
# omcicli mib get 11
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
EthUni
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
=================================
EntityID: 0x0101
ExpectedType: 47
SensedType: 47
AutoDectectCfg: 0
EthLoopbackCfg: 0
AdminState: 0
OpState: 1
DuplexInd: 0
MaxFrameSize: 1518
DTEorDCEInd: 0
PauseTime: 0
BridgedorIPInd: 2
ARC: 0
ARCInterval: 0
PppoeFilter: 0
PowerControl: 0
PhysicalPortId: 65535
=================================Je vais retenter downgrade vers version précédente quand j'ai un peu de temps.
Edit : confirmé, un downgrade vers V4.2.4L5 suivi de
echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability
killall omci_apprétablit la connexion. Je fais suivre le retour à Marcin également.
Edit2 : Leox prépare un nouveau firmware.
-
Je reviens là-dessus car la mise à jour du firmware ne s'était pas passée (j'avais oublié de remettre HW_HWVER sur LXE-010X-A, donc malgré les indication d'upload du FW et du redémarrage, ça tournait toujours sur le FW d'avant).
Mais sur le V4.2.4L5, tu ne devais pas avoir le "0;0;0;0;0;0;2" non plus par défaut.
Après avoir refait la mise à jour comme il faut pour être sur V4.2.4L6a2, ça ne marche plus :
Sur ce firmware tu devrais déjà avoir 0x101, sans toucher à /proc/realtek/uni_capability.
Sauf que tu as "PhysicalPortId: 65535" (je n'avais pas fait attention, mais c'était pareil pour @fcueto).
Donc ils ont probablement patché le mapping port => UNI, mais pas le mapping UNI => port.
Edit2 : Leox prépare un nouveau firmware.
Ou tu restes sur le V4.2.4L5, et tu mets la commande dans le /var/config/run_customized_sdk.sh.
-
Ça marche ! (avec VLAN 832 côté routeur)
Bonjour, est-ce qu'il y a une liste des commandes nécessaires quelque part pour faire fonctionner ce Leox en bypass Orange ?
Merci :)
-
Bonjour, est-ce qu'il y a une liste des commandes nécessaires quelque part pour faire fonctionner ce Leox en bypass Orange ?
Merci :)
Pour le paramétrage, @thinklad avait fait (https://lafibre.info/remplacer-livebox/onu-compatible-xgs-pon-orange/msg1093805#msg1093805
flash set GPON_SN SMBSxxxxxxxx
flash set PON_VENDOR_ID SMBS
flash set OMCC_VER 128
flash set HW_HWVER SMBSXLB7400
flash set OMCI_SW_VER1 SAHEOFR070202
flash set OMCI_SW_VER2 SAHEOFR070101
flash set OMCI_TM_OPT 0
flash set OMCI_OLT_MODE 1
Mais il est probable que tout ne soit pas nécessaire.
Si c'est comme en GPON, je dirais GPON_SN + PON_VENDOR_ID de base, et HW_HWVER nécessaire sur les OLT ALCL.
Il faut également faire :
echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability
killall omci_app
(normalement automatisable via /var/config/run_customized_sdk.sh)
Mais pour l'instant il ne s'agit que d'une seule personne, sur OLT ALCL et avec peu de VLAN.
On n'a plus de retour de @fcueto, qui a plus de VLAN.
-
Bonjour,
désolé pour le délai dans ma réponse mais j'ai eu 2 semaines de folie au taff et je n'ai pas eu de temps à consacrer aux tests d'ONT...
Je viens de tester ce week-end un nouveau firmware envoyé par Marcin qui "intègre" l'équivalent de la commande donnée par hwti. Et cela fonctionne parfaitement, dès le boot de l'ONT. Il n'y a aucune commande à envoyer.
Et chez moi tout fonctionne : internet, la tv, le téléphone donc j'imagine que tous les VLAN sont bien gérés.
N'hésitez pas à me MP pour avoir ce firmware.
-
N'hésitez pas à me MP pour avoir ce firmware.
Pourrais-tu partager ici le numéro de version du firmware, pour référence ?
-
oui c'est la version V4.2.4L6a3
-
Que donne "cat /proc/realtek/uni_capability" ?
C'est pour savoir si il y a juste la commande, ou un équivalent kernel ou device-tree ou plutôt un patch sur le démon OMCI.
En tout cas, c'est une bonne nouvelle, le nombre de VLAN ne semble donc pas être un problème (et le mappping 2800 -> 832 non plus, mais c'était déjà confirmé pour @thinklad).
-
# cat /proc/realtek/uni_capability
# port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;2
# OMCI claim port capability
# From left, physical uni 0, uni 1, uni 2...
# 40GE 7, 25GE 6, 10GE 5, 5GE 4, 2.5GE 3, GE 2, FE 1, None 0
0;0;0;0;0;0;2
# logical port to physical port remapping
# -1: invalid port
6;-1;-1;-1;-1;-1;-1;-1
#
-
Donc les deux lignes "port capability" et "OMCI claim port capability" changent.
Le "echo "SPEED 0;0;0;0;0;0;2" > /proc/realtek/uni_capability" ne modifie que la première.
Je ne sais pas ce que la 2ème ligne fait.
-
J’ai également récupéré (et installé) la version V4.2.4L6a3 auprès de Marcin, et je la mets à disposition ici pour ceux qui en auraient besoin : https://leox.pages.dev
(En attendant une confirmation que la modification apportée par ce firmware est bien incluse dans les unités vendues.)
-
J’ai également récupéré (et installé) la version V4.2.4L6a3 auprès de Marcin, et je la mets à disposition ici pour ceux qui en auraient besoin : https://leox.pages.dev
(En attendant une confirmation que la modification apportée par ce firmware est bien incluse dans les unités vendues.)
Alors ça c'est sûr et certain que non, Marcin l'a déjà indiqué, les modifications qu'il a faites pour nous ne seront pas intégrées dans le firmware "mainline".
J'en profite pour partager quelques infos supplémentaires qu'il m'a envoyé ce matin.
Voici ma question et sa réponse:
Q : It would be nice if the 2 changes you made can be integrated in the main line of future firmwares. I mean for example adding a parameter somewhere to change the 10G LAN port to be 0x101 and not 0xa01.
R: Please remember - this device is not designed to be used as replacement.
It is designed to be used by telco operators, so they can properly configure their OLTs with ONT.
FunBOX 10 is specific. Normally routers like FB10 use VEIP for provisioning. But - in case of OFR - FB10 emulates SFU, so it pretends it is single port L2 ONT.
In case of GPON, such ports usually are located on slot 1, port 1 (0x101)..
10GE port is bit different. We have checked several SFUs (1x10GBaseT) ONTs - and it uses different slot - like slot 10 (0xa).
Now - most probably - how it is configured will depend on particular telecom requirement. And this will be hardcoded in firmware, as no telecom will log in to device and change it.
Such hardcoding is simple, but makeing it configurable would require lot of patching in OMCI stack.
I'am not sure if it will ever make it, as it is much less time to rebuild an image with different slot enforcement.
btw. in firmware that works for you, it presents as plug in unit type - 47, so it is gigabitethernet.
In fact, it should be type 49 (10GE).
In case co regular operations and control of OLT - using wrong unit type will make it impossible to read LAN port speed properly from OLT perspective.
Je ne comprends pas trop l'implication de ce qu'il explique en dernier. J'espère que l'OLT ne va pas limiter la vitesse à 1Gb ?
-
Tant qu'on n'a pas besoin de valeurs arbitraires, on peut utiliser un script de toute façon.
Le type de port ne semble pas gêner dans les tests de @thinklad (sur OLT ALCL), au moins pour le download.
Sur les HWTC, on ne sait pas (mais peut-être que le 0x101 ne sera pas nécessaire, chez Bouygues le 0xa01 fonctionne).
Si jamais ça gêne, il faudra patcher le code OMCI.
-
J’ai également récupéré (et installé) la version V4.2.4L6a3 auprès de Marcin, et je la mets à disposition ici pour ceux qui en auraient besoin : https://leox.pages.dev
(En attendant une confirmation que la modification apportée par ce firmware est bien incluse dans les unités vendues.)
Le kernel a été recompilé, et par rapport à la V4.2.4L5 il y a des choses qui bougent (je ne sais pas si c'est volontaire), en tout cas je vois que pour /proc/realtek/uni_capability, "0;0;0;0;0;0;5" a été changée en "0;0;0;0;0;0;2".
Pour le rootfs, il y a peu de changements :
- mib_Anig.so : la fonction anig_test_handler a été modifiée
- mib_EnhancedSecCtl.so : décalage de 2 lignes dans un fichier source (traces) sans autre conséquence
- busybox a été recompilé, et ça décale des offsets ("BusyBox v1.22.1 (2024-11-25 15:59:41 CET)" est plus court que "BusyBox v1.22.1 (2024-07-16 16:00:49 CEST)"), il n'y a probablement pas de changement
- la date de build change aussi dans libcrypto.so.1.1, ca-plat-kernel.ko
- /etc/release_date et /etc/version changent
- la version change dans /home/httpd/web/index.html et /home/httpd/web/index_user.html
-
Merci pour les infos, ça fonctionne ici (version V4.2.4L6a3), actuellement limité en vitesse par le routeur mais upgrade bientôt j'espère.
-
Le kernel a été recompilé, et par rapport à la V4.2.4L5 il y a des choses qui bougent (je ne sais pas si c'est volontaire), en tout cas je vois que pour /proc/realtek/uni_capability, "0;0;0;0;0;0;5" a été changée en "0;0;0;0;0;0;2".
Pour le rootfs, il y a peu de changements :
- mib_Anig.so : la fonction anig_test_handler a été modifiée
- mib_EnhancedSecCtl.so : décalage de 2 lignes dans un fichier source (traces) sans autre conséquence
- busybox a été recompilé, et ça décale des offsets ("BusyBox v1.22.1 (2024-11-25 15:59:41 CET)" est plus court que "BusyBox v1.22.1 (2024-07-16 16:00:49 CEST)"), il n'y a probablement pas de changement
- la date de build change aussi dans libcrypto.so.1.1, ca-plat-kernel.ko
- /etc/release_date et /etc/version changent
- la version change dans /home/httpd/web/index.html et /home/httpd/web/index_user.html
I did not expect you analyse it so deeply ;)
Recently I have changed SDK to bit newer, but it fixes some little issues.
aniG is updated so it support Huawei OLT optical signal level readout.. well, if you have OLT, you could now get optical signal level properly, as Huawei does not keep standards.... so from private person perspective it is meaningless...
EnchancedSecurityControl - that ME is used by Huawei to authenticate ONT if you replace PON_VENDOR_ID to HWTC and OLT is HWTC.
Well... in case of GPON - they didn not care... in case of XGSPON - huawei does not like it anymore so extra authentication is added.
And it is different than default setting. Maybe they use different encryption key than the one in code, but maybe also response calculations are modified... no one hacked yet....
In general, if I do "make clean", more things get rebuild ;)
-
I did not expect you analyse it so deeply ;)
Well, I just used strings and diffoscope.
I wanted to know if you changed something on the OMCI side, or only the /proc/realtek/uni_capability (it looks like you only changed the kernel config or code for this, the strings suggest the value could also be set in the device-tree).
EnchancedSecurityControl - that ME is used by Huawei to authenticate ONT if you replace PON_VENDOR_ID to HWTC and OLT is HWTC.
Well... in case of GPON - they didn not care... in case of XGSPON - huawei does not like it anymore so extra authentication is added.
And it is different than default setting. Maybe they use different encryption key than the one in code, but maybe also response calculations are modified... no one hacked yet....
Do you mean HWTC OLTs will authenticate HWTC ONUs, but still allow other vendors ?
In France, both Orange and Bouygues have SMBS as vendor id, as the Livebox 7 and BBox Ultym are made by SagemCom.
There is no authentication issue, with the most tested ONUs being WAS-110 (MaxLinear), XGS-ONU-25-20NI (Cortina).
The LXE-010X-A has only been tested on ALCL OLTs on Orange (AFAIK).
But HOSECOM X67S / AIWOKS AW-XGP12V (also RTL9615C) works on an HWTC OLT on Bouygues.
In general, if I do "make clean", more things get rebuild ;)
The Busybox binary will change on each build, unless setting KCONFIG_NOTIMESTAMP, or SOURCE_DATE_EPOCH (only added in 1.34.0).
But having reproducible builds is probably useless for you, it would only help when comparing firmwares like I did.
-
Well, I just used strings and diffoscope.
I wanted to know if you changed something on the OMCI side, or only the /proc/realtek/uni_capability (it looks like you only changed the kernel config or code for this, the strings suggest the value could also be set in the device-tree).
Do you mean HWTC OLTs will authenticate HWTC ONUs, but still allow other vendors ?
In France, both Orange and Bouygues have SMBS as vendor id, as the Livebox 7 and BBox Ultym are made by SagemCom.
There is no authentication issue, with the most tested ONUs being WAS-110 (MaxLinear), XGS-ONU-25-20NI (Cortina).
The LXE-010X-A has only been tested on ALCL OLTs on Orange (AFAIK).
But HOSECOM X67S / AIWOKS AW-XGP12V (also RTL9615C) works on an HWTC OLT on Bouygues.
The Busybox binary will change on each build, unless setting KCONFIG_NOTIMESTAMP, or SOURCE_DATE_EPOCH (only added in 1.34.0).
But having reproducible builds is probably useless for you, it would only help when comparing firmwares like I did.
Huawei authenticates only original Huawei ONTs (with PON venodor ID = HWTC).
It does not authenticates others.
From your perspective - if you want to replace Huawei ONT with like LEOX - and if you set PON_VENDOR_ID = HWTC - it will fail authentication.
You can allways leave LEOX, but - if OLT owner does not have 3PP Licenense on Huawei OLT - it will also fail.
It's a kind of protection to skip license limitations in case of ISPs using Huawei OLTs without 3PP license, or to enforce them to buy Huawei ONTs...