Messages récents

Pages: [1] 2 3 4 5 6 ... 10
1
K-Net Espace technique internet K-Net / Coupures à répétition (91)
« Dernier message par corteg le Aujourd'hui à 08:36:53 »
Le plus extraordinaire pour moi c'est qu'il y ait encore des gens qui s'accroche chez K-net. Je suis passé chez Orange il y a quelques mois et c'était déjà la déroute totale depuis des mois. Je n'ai plus de problème depuis et j'ai donc regretté de ne pas l'avoir fait plus tôt. A mon avis K-net est mort depuis plus d'un an, voire deux, c'est largement suffisant pour décider d'aller voir ailleurs
2
Pour info, la boutique Knet d'Epinay sur Orge est fermée 15 jours ... pour cause de travaux !!!
C'est le cas aussi mais pour une durée indéterminée de leur Service Client sur le Net --> 502 Bad Gateway !

En revanche, la Poste d'Epinay est ouverte pour accueillir la lettre de résiliation de mon contrat Knet souscrit en mars 2014 et mercredi je serai en principe raccordé à Bouygues, car les coupures constatées depuis le début juillet et sans explication de leur part sont inacceptables.

C'est dommage, car jusqu'à l'été 2022, j'étais satisfait du service rendu par la société de Frank Bisetti au cours des 8,5 années passées ensemble.
3
K-Net Actus K-Net / Suivi hebdomadaire Abo/Résiliation suite incidents fin 2021 début 2022
« Dernier message par Fyr le Aujourd'hui à 05:50:08 »
Si vous êtes éligibles ailleurs, allez y.

Ne remuez pas votre dossier bien enterré, vous êtes hors scope d'un quelconque process industriel ou artisanal chez K-net, aucune chance d'avoir autre chose qu'un electro-encephalo plat.
4
j’ai réussi grâce à toi notamment à le passé sous Carlitoxx (preuve étant fw_setenv ont_serial NSERIE ne m’a pas retourné de message d’erreur) mais dans la Pro dure je ne trouve pas le fichier sys.sh dans l’endroit indiqué.
Si tu n'as pas de sys.sh, à priori tu n'es pas sur le firmware Carlitoxx.
J'ai regardé le contenu du mA5671a_root_mtd2.img du tuto.7z du proap, c'est bien un firmware Huawei.
fw_setenv peut positionner n'importe quelle variable, ce n'est pas pour autant qu'elle sera lue.

Je pense donc que le SN n'est pas renseigné, mais c'est bizarre d'avoir déjà O5 (peut-être un OLT ALCL).
Vérifie avec "onu gtcsng", si tu n'as pas le SN comme je le pense, tu peux le renseigner temporairement avec "onu gtcsns SMSBxxxxxxxx".
Ensuite tu peux vérifier si tu as les VLAN (peut-être que si tu étais dans un faux O5 avant, il faut débrancher la fibre, attendre un peu, puis la rebrancher).

Si après tu n'as toujours pas de VLAN, alors tu est probablement sur un OLT ALCL, et il faut modifier le fichier MIB comme j'ai indiqué.
Il faut d'abord vérifier "fw_printenv mib_file" et "uci show omci.default.mib_file" pour voir si le nom du fichier à utiliser n'a pas été modifié, mais c'est peu probable.
Ce serait donc  /etc/mibs/data_1g_8q.ini, qui est dans le mA5671a_root_mtd2.img.

Il faudra également modifier sfp_a2_info comme je l'ai indiqué pour que le SN soit appliqué automatiquement à chaque reboot.
5
fibre Installation de la fibre / GPON-ONU-34-20BI fonctionnel mais très lent...
« Dernier message par hwti le Aujourd'hui à 03:29:08 »
Pour ce qui est du comportement de l'ONT, s'il n'y a pas de problème de niveau de signal, peut-être qu'il y a des différences dans la gestion de traffic.
Je sais que certains ont des problèmes de débit avec le GPON-ONU-34-20BI, mais à priori c'est uniquement en upload (chez Bouygues par exemple).
Avec Bouygues, avec un DFP-34X-2C2 (Realtek), avec le OMCI_WAN_QOS_QUEUE_NUM=0 par défaut, les débits sont très faibles dans les deux sens, et avec 4 tout se passe bien.
Donc on peut avoir soit un OLT qui exige un nombre suffisant de files, ou alors un ONT qui bride très fortement quand l'OLT a poussé une configuration avec plus de files que ce qu'il y a de configuré.

Sur le G-010S-A, avec la fibre connectée, on peut faire :
omcli omciMgr redirect /dev/pts/0
omcli console displaymibs all
Ca va donner énormément d'informations.

Sur le GPON-ONU-34-20BI, c'est le mib file qui configure tout.
On peut soit regarder le mib file, déjà son nom donne des informations sur la configuration.
On peut également lancer "omcid -c", et utiliser les commandes :
 - help (si besoin)
 - md (mib_dump)
 - mda (mib_dump_all)
A voir ce que ça donne.

L'idée est d'essayer de comparer les différentes configurations qui pourraient être liées à la gestion des débits.
Ca peut aussi bien être ce que l'ONT expose, que ce que l'OLT configure.
Pour ça il faut regarder avec la spec OMCI.

Pour les capacités déclarées par l'ONT, le G-010S-A a :
 - dans ONTGpon, "Traffic Management:     0x02" (pour "Priority and rate controlled") à priori
 - dans ONT2Gpon, il y a "Total priority queue number" et "Total traffic scheduler number" (sur le GPON-ONU-34-20BI, ça dépend probablement du MIB file), et "QoS configuration flexibility"

Selon la spec, dans les valeurs intéressantes qui peuvent être lues et/ou positionnées par l'OLT, on a :
 - Circuit Pack (ME #6) (éventuellement)
 - GEM Port Network CTP (ME #268)
 - Priority Queue (ME #277)
 - Traffic Scheduler (ME #278)
 - Traffic Descriptor (ME #280)
Là c'est assez compliqué, on peut essayer de comparer les deux pour voir si sur le GPON-ONU-34-20BI il y aurait des "pointeurs" cassés ou des tables tronquées (si par exemple l'OLT demande trop de files par rapport à ce qui est supporté).
6
fibre Installation de la fibre / GPON-ONU-34-20BI fonctionnel mais très lent...
« Dernier message par hwti le Aujourd'hui à 03:27:38 »
Le "correctif" du G-010S-A, c'est le mod de la broche 6 ?


D'abord, il faudrait faire des tests iperf3 en UDP pour vérifier si le problème est bien dans les deux directions, ou si les pertes très importantes dans un sens pénalisent aussi l'autre en TCP.
Je donne l'exemple avec un serveur FR, mais ce serait mieux d'en avoir un plus proche :
 - iperf3 -c speedtest.milkywan.fr -p 9200 -u -b 500M -R
 - iperf3 -c speedtest.milkywan.fr -p 9200 -u -b 500M
7
Occitanet Occitanet / Des retours sur Occitanet ?
« Dernier message par thenico le Aujourd'hui à 03:14:28 »
Probablement la porte de collecte national d'Altitude Infra.
8
hébergement WiFi / Wifi 5 GHz canal 144 (5710-5730 MHz), DFS ou SRD ?
« Dernier message par mrintrepide le Aujourd'hui à 02:30:15 »
Voici la réponde de l'ANFR

Citer
Bonjour,
Le canal 144 n'est pas autorisé d'usage en Europe, les canaux sélectionnables dans le cadre de communications WiFi doivent utiliser uniquement des fréquences comprises à l'intérieur des bandes autorisées (5150-5350 MHz et 5470-5725 MHz / Porteuse + bande passante).
La bande 5725-5875 MHz est une bande de plein droit autorisée à tous les équipements de faible puissance et faible portée avec une puissance d'émission maximale de 25mW.
Seul le marquage CE présent sur les équipements et la déclaration de conformité accompagnant le produit  permettent de garantir sa conformité aux normes européennes et d'autoriser sa libre circulation au sein de l'Union Européenne.
Une vigilance accrue doit être faite sur la conformité d'équipements achetés hors UE et sur leur utilisation en France.
Je vous informe également qu'en cas de brouillage avéré par une utilisation incorrecte d'un tel équipement, la responsabilité pénale de l'utilisateur peut être engagée. La réglementation française sanctionne notamment d'une peine pouvant aller jusqu'à six mois d'emprisonnement et 30 000 € d'amende (article L 39-1 du code des postes et des communications électroniques):
  - l'utilisation d'un équipement radioélectrique non conforme ;
  - le fait de brouiller en ne respectant pas les conditions d'utilisation du matériel en France."

Cordialement.

Le Département Surveillance du Marché / Radio Equipment Market Surveillance Department

Agence nationale des fréquences
Direction de la Surveillance du marché et de l'Exposition
Pôle technique de Saint-Dié
9
bistro Bistro / Découverte d'une armoire de contrôle de feux tricolores à Paris
« Dernier message par PhilippeMarques le Aujourd'hui à 02:26:13 »
Non, il y a déjà en embarqué de l' IA dans les véhicules et le fonctionnement fait que c'est le véhicule qui s'adapte à l'environnement, les évolutions vont vers une gestion fonction du gps et de la cartographie des voies de circulation. Pour l'instant ce mode de fonctionnement est surtout utilisé sur les autoroutes, mais si l'on souhaite poursuivre en ville et les recherches vont tendre à enlever la capacité aux conducteurs de faire des erreurs.
La liaison avec les sémaphores, l' IA embarquée, est toute trouvée.
Il faut lier les deux, le système de supervision humain de contrôle existe, c'est le centre de contrôle au sein de la préfecture, celui de pilotage du traffic serait certainement à améliorer par une indication de capteurs supplémentaires et l'incorporation de cette IA à l'automatisme du sémaphore.

Openpilot :

openpilot is an open source driver assistance system. openpilot performs the functions of Automated Lane Centering and Adaptive Cruise Control for over 200 supported car makes and models.

https://github.com/commaai/openpilot
10
mtd2 et mtd5 sont les deux images utilisées normalement de manière alternative pour les mises à jour, donc si on a modifié mtd2 et on démarre dessus, modifier mtd5 en plus ne change rien.

La méthode de la p82 fait le backup et le flashage de mtd2 depuis le bootloader (ce qui fait le root).

L'autre méthode fait le "sed -i  "s|/opt/lantiq/bin/minishell|/bin/ash|g" /etc/passwd" depuis le port série dans Linux.
Ensuite c'est rooté, puisqu'il y a l'accès root en ssh.
On peut faire un backup depuis le ssh, ce qui peut être utile.
Mais pour ce qui est de flasher mtd2/mtd5, je ne sais pas à quoi ça sert dans ce cas.
Le "fw_setenv ont_serial", c'est uniquement pour des firmwares Carlitoxx ou autres.

Dans tous les cas, tu peux tester le SN temporairement sans aucune modification avec "onu gtcsns SMBSxxxxxxxx".
Normalement ça devrait être suffisant pour passer en O5 à vérifier avec "onu ploamsg".

Sur un OLT HWTC, ça peut être suffisant pour avoir l'ONT fonctionnel (sauf que le SN est perdu au reboot).
Sur un OLT ALCL, il faut Hardware Version, donc c'est plus compliqué.

Si tu as flashé l'image de la p82, ça semble être un firmware d'origine, donc :
 - Le SN est dans sfp_a2_info (cf https://forum.openwrt.org/t/support-ma5671a-sfp-gpon/48042/25) : pour simplifier tu peux utiliser https://gpon-sfp.felix.systems/gen_huawei.php : tu lui donnes le résultat de "fw_printenv sfp_a2_info" (begin-base64 ...), tu renseigne le numéro de série et du choisis "Modify and generate new data", et ensuite fw_setenv sfp_a2_info "..." en mettant la valeur modifiée donnée
 - dans le MIB file ("fw_printenv mib_file" et "uci show omci.default.mib_file" pour voir s'il y a un fichier particulier utilisé, sinon c'est /etc/mibs/data_1g_8q.ini)
256 0 HWTC CC4.A\0\0\0\0\0\0\0\0 00000000 2 0 0 0 0 #0=>
256 0 SMBS SMBSSGLBF121\0 00000000 2 0 0 0 0 #0Ca permet normalement de changer :
 - Vendor ID : je ne sais pas si les OLT utilisés par Orange l'exigent, mais la norme dit que ça doit correspondre aux 4 premières lettres du SN => SMBS
 - Hardware Version : c'est nécessaire pour les OLT ALCL (pas pour HWTC)
Il faut redémarrer pour que ce soit pris en compte.

Oui je comprends pour le fichier data_ …. , ce serai comme l’ONU de FS.COM mais je n’ai pas regardé de ce côté là, en fait ne l’ayant pas trouvé…
j’ai réussi grâce à toi notamment à le passé sous Carlitoxx (preuve étant fw_setenv ont_serial NSERIE ne m’a pas retourné de message d’erreur) mais dans la Pro dure je ne trouve pas le fichier sys.sh dans l’endroit indiqué.
Du coup les VLAN ne remontent pas en faisant gtop c+v ou c+x

Par contre avec onu ploamsg je suis bien en O5
Comment trouver sys.sh ? Ou le fichier data_ … dans carlitoxx ?
J’ai suivi la procédure auto pour le root (que tu m’as donné ;) et après j’ai suivi la deuxième parti du tuto de proap

Merci infiniment de tes lumières ;)

Pages: [1] 2 3 4 5 6 ... 10