Messages récents

Pages: 1 2 3 4 [5] 6 7 8 9 10
41
Bonjour à tous,

Merci pour ces informations complémentaires, elles m'aident beaucoup à y voir plus clair.

Pour vous situer où j'en suis :
en parallèle de ma question sur le forum, j'avais adressé le 04/09/2026 une demande détaillée à l'assistance Free concernant le passage de P2P à PON, voici la réponse du conseiller :
"Avec ce type de raccordement issu d'anciennes infrastructures (ex Numericable), le débit maximal délivré sur la ligne est techniquement limité à 1 Gbit/s partagé. Il n'est donc pas possible d'atteindre les 2,5 Gbit/s sur votre port Ethernet dans cette configuration."

le 05/09/02026
Voici le message que je leur avais envoyé :

"Objet : Demande de migration vers l'infrastructure 10G-EPON (Quartier éligible 8 Gbps)
Bonjour,
Je vous remercie pour votre retour, mais il y a une confusion technique dans votre réponse.
Mon logement n'est pas sur une infrastructure ex Numericable (coaxial), mais bel et bien sur une vraie ligne de fibre optique (FTTH) Free en Point à Point (P2P).
Le syndic de mon immeuble n'a aucun pouvoir sur les équipements internes de Free.
L'immeuble est déjà entièrement fibré.
De plus, le test d'éligibilité officiel à mon adresse exacte (et sur les adresses voisines) affiche désormais une éligibilité commerciale chez Free à 8 Gbit/s.
Cela prouve techniquement que le NRO de mon quartier a été modernisé et qu'il est actif pour la technologie 10G-EPON.
Le goulot d'étranglement vient uniquement du fait que ma ligne n'a pas encore été basculée (migrée) de l'ancienne carte P2P vers la nouvelle carte PON au sein de votre répartiteur.
Le réseau de mon quartier étant prêt, je vous demande de bien vouloir transmettre mon dossier au service réseau afin de planifier la migration physique de ma ligne vers le protocole 10G-EPON.
Dans l'attente de votre confirmation ou de la planification de cette bascule réseau.
Bien cordialement,"

Le conseiller m'avait alors indiqué qu'il allait se renseigner en interne.

Le 09/09/2026, j'ai subi une coupure totale de connexion, avec un message sur la box indiquant l'étape 3a (signal fibre P2P détecté, puis non détecté), sans aucun avertissement préalable de la part de Free. Étant en télétravail ce jour-là, l'expérience n'a pas été des plus agréables.

J'ai donc contacté l'assistance pour comprendre l'origine de cette coupure, en leur demandant si elle était liée au passage vers le PON 10 Gbit/s, et en soulignant qu'une notification préalable aurait été appréciable dans ce genre de situation.

Entre-temps, j'ai reçu un message m'informant que des techniciens intervenaient sur ma ligne.
L'assistance m'a ensuite confirmé la perte de signal, précisé qu'un opérateur agissait à l'extérieur, évoqué une possible intervention technicien, et programmé un rappel pour s'assurer que tout soit rétabli.

Quelques minutes plus tard, un rendez-vous m'a été proposé.
J'ai demandé s'il s'agissait d'une simple réparation ou du changement vers le PON 10 Gbit/s, dans l'espoir d'obtenir enfin une réponse claire sur ma demande de migration.
J'ai tout de même validé ce rendez-vous pour le lendemain après-midi (10/09/2026), les jour et horaire proposés me convenant.

La réponse obtenue fut la suivante : "Oui en effet lorsqu'il y a une étape 3a. Le rdv est nécessaire. Je reste à votre disposition." — une réponse qui, malheureusement, n'apportait toujours aucun éclaircissement sur ma demande de migration.

Trois heures plus tard, ma connexion était rétablie.

Le 10/09/2026 à 6h00, le rendez-vous a été annulé sans explication.

Le 11/09/2026, j'ai reçu ce message : "Je constate que vos services sont fonctionnels. Par ailleurs, mon collègue vous a bien dit que l'opérateur immeuble de la fibre est bien Numéricâble et non Free."


Je constate donc que l'assistance ne répond toujours pas à mes questions, et qu'elle continue de me communiquer et de confirmer des informations erronées.

D'après vous, que dois-je faire pour la suite ?

Par ailleurs, je tiens à remercier Busyspider pour son message : j'en ai bien pris connaissance, et cela m'aide à mieux comprendre comment cette migration est censée se dérouler.
42
SFR Actus SFR Altice / Installation de Connect TV d'SFR sur box Android TV
« Dernier message par weezer le Hier à 12:46:24 »
Hello,
Je passe par atv tools il me dit invalid apk,  erreur de ressources lors de l'instalation sur la box
D'ailleurs plus moyen d'installer la version officielle (non moddée) également,  alors que ca s'installait avec les dernieres versions précédentes
43
Free Mobile Actu Free Mobile / Conseils pour téléphone VoLTE
« Dernier message par ben_becker le Hier à 12:26:00 »
Ne prend pas juste un téléphone compatible VOLTE.
Prend un téléphone qui est dans la liste officielle de Free
https://assistance-1.free.fr/mobile/terminaux/

Leon.
J'en avais repéré un sur le site de Free, c'était le TCL 4043 mais ils l'ont supprimé du site, plus en stock ?
Il ne reste que le TCL 5041 et les avis laissés par les clients ne semblent pas bon, problème d'écho pendant les appels, faible autonomie...
En espérant que le 4043 soit à nouveau disponible.
Et j'ai vérifié les 2 TCL sont compatibles B28
44
Bonne nouvelle : avec le tout nouveau firmware G03.R09.C02_02 en cours de déploiement sur les LB7W7 la génération de la documentation des APIs est de nouveau possible à quelques petits détails près.
Résultat publié sur le repo : https://github.com/p-dor/LiveboxMonitor/tree/main/docs/API%20Documentation/Livebox%207%20W7

Je vais du coup réactiver le bouton pour les LBS et LB7W7 dans la prochaine version et simplement retourner une erreur si quelque chose se passe mal sur certains modèles...
45
Free Mobile Actu Free Mobile / Conseils pour téléphone VoLTE
« Dernier message par Leon le Hier à 12:07:17 »
Ne prend pas juste un téléphone compatible VOLTE.
Prend un téléphone qui est dans la liste officielle de Free
https://assistance-1.free.fr/mobile/terminaux/

Leon.
46
Free Mobile Actu Free Mobile / Conseils pour téléphone VoLTE
« Dernier message par ben_becker le Hier à 12:03:30 »
Bonjour

La 2G va bientôt s'éteindre et mon père n'a toujours pas changé son téléphone 2G.
Il ne veut pas de smartphone, juste un téléphone à touches à l'ancienne.
Il est chez Free mobile, est-ce que c'est important si le téléphone est compatible ou non à la fréquence LTE B28 70 MHz ?
Car j'ai vu des téléphones qui n'avaient pas cette fréquence, pour d'autres modèles ils ne précisent pas les fréquences ils disent juste compatible 4G.
47
J'ai toujours le même problème aussi, sur un tunnel Wireguard entre deux connexions FTTH Orange (une FTTH Sosh avec Livebox 5, et une FTTH Orange avec routeur perso sans Livebox).

J'avais bricolé un ONT externe derrière la Livebox côté Sosh pour pallier le problème, mais j'ai dû récemment le retirer et revenir à l'ONT interne de la Livebox. Au bout de quelques jours seulement, le shaping à 5 Mbit/s est revenu sur le tunnel Wireguard.

En revanche, sur la connexion derrière la Livebox j'ai été obligé de mettre sur l'interface Wireguard une règle Pre-Up iptables qui supprime tous les tags DSCP, sinon la connexion est bridée ad vitam aeternam à 5 Mbps.

J'ai tenté ça mais ça ne change rien, de base mes paquets Wireguard sortent déjà avec un ToS 0 (sur la machine dans le LAN de la Livebox) :

10:05:23.238828 IP (tos 0x0, ttl 64, id 17744, offset 0, flags [none], proto UDP (17), length 1400)

Par contre ces mêmes paquets arrivent avec un ToS 0x88 côté FTTH Orange (le côté sans Livebox) :

10:06:38.186404 IP (tos 0x88, ttl 60, id 19906, offset 0, flags [none], proto UDP (17), length 1400)

Donc ça ressemble vraiment à un élément du réseau côté émetteur (soit Livebox, soit ONT interne, soit OLT...) qui change le ToS de mes paquets Wireguard, et ensuite c'est shapé par le réseau d'Orange...
48
@unipo :

Recopier la configuration est efficace, mais ce n'est pas la méthode recommandée. Il aurait idéalement fallu aller un cran plus loin.
Car cela inclut les erreurs éventuelles et redéfinit également certaines valeurs par défaut.

Citation de: Wiki nftables
You could use meta l4proto to match on the transport protocol (ie. TCP, UDP, ICMPv6,...), this is walking down the headers until the real transport protocol is found.

If you specifically want to match on the ICMPv6 type, then nftables creates an implicit meta l4proto dependency that is not shown, therefore, there is no need for being verbose in your notation, ie.

% nft add rule filter input icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
works fine to accept all ICMPv6 traffic regardless any possible extension headers.

Hyperlink: Matching IPv6 headers

Exemple d'erreur dans la configuration

nft add rule inet fw4 mangle_postrouting oifname "eth0.832" ip protocol icmpv6 counter meta priority set 0:6

nft add rule inet fw4 mangle_postrouting oifname "eth0.832" meta l4proto ipv6-icmp counter meta priority set 0:6

Citer
l4proto <protocol>

Protocol numbers assigned by IANA
49
SFR Actus SFR Altice / Installation de Connect TV d'SFR sur box Android TV
« Dernier message par yarienavoir le Hier à 09:23:58 »
Bonjour,
Pas réussi à faire fonctionner la dernière version 8.3.0 b1 dev-mode dispo ?
a.smali trouvé et patché mais après compilation j'ai l'impression que la signature ne s'applique pas
Cdt
50
Bonjour,

Je poste un nouveau sujet plutôt que de remonter le fil "Firmware LB7W7" pour décrire un problème précis, mesuré, et voir qui est dans le même cas. Je résume d'abord les faits, ensuite l'hypothèse.

Matériel et contexte
  • Livebox 7 "W7" (Sagemcom F@st 5698), firmware SGW7-fr-G03.R08.C03_00, XGS-PON.
  • Lien optique parfait : Rx -18,5 dBm, 0 erreur, ONT en O5, identique avant et après les incidents.
  • Wi-Fi maison assuré par un mesh Netgear Orbi (RBR350 + 2 RBS350) en mode point d'accès, backhaul Wi-Fi, branché sur un port Ethernet de la box. Wi-Fi de la Livebox inutilisé.
  • La box a déjà été échangée deux fois par Orange (deux Livebox 7 neuves) : problème strictement identique. Le RAZ usine ne change rien non plus.

Symptômes
  • Redémarrage spontané toutes les 2 h 20 à 2 h 30 environ, jour et nuit. L'historique interne de la box donne à chaque fois BootReason = "Oops" (plantage noyau), sans arrêt propre. Compteur de boots passé de 47 à 66 en quelques jours.
  • Variante pire : la box "gèle" au lieu de rebooter. DNS, interface web et API morts, mais le routage IP continue (0 ping perdu vers l'extérieur). Parfois elle finit par rebooter seule après 10-20 min, parfois il faut la débrancher (55 min de gel constaté).

Ce que j'ai mesuré
J'interroge l'API interne de la box (celle du webui) toutes les 10 s depuis un PC : mémoire libre, uptime, événements, DNS.
  • Fuite mémoire linéaire : la mémoire libre passe de ~1 200 Mo après boot à moins de 40 Mo, à 5-10 Mo/min selon les moments. À ~40 Mo le DNS de la box meurt, puis l'API, puis Oops et reboot. Période = 1 200 Mo / pente = les 2 h 30 observées. C'est reproductible cycle après cycle, une nuit entière.
  • La fuite n'a lieu que quand les appareils du foyer sont présents (téléphones Apple sur le mesh). Maison vide 46 h : mémoire stable à 1 240 Mo, zéro plantage. Retour des habitants : plantage 2 h 15 plus tard.
  • Tempête d'événements de topologie : le canal d'événements de la box débite ~2 000 événements/min en permanence. Ce sont tous du même type : la box s'enregistre elle-même comme "fille" de l'un des deux satellites Orbi, puis de l'autre, plusieurs fois par seconde (add/delete de son propre lien amont). CPU de la box à 45-60 % au repos.

Ce que montre l'API sur le mesh
  • Les trois nœuds Orbi sont découverts par la box via IEEE 1905.1 (EasyMesh), tagués "ieee1905 almac", pas via DHCP.
  • La box n'est pas un simple observateur : elle est un agent 1905 actif, avec sa propre adresse d'agent (02:00:00:xx:xx:xx). Le routeur Orbi la liste dans sa table de voisins 1905 au même titre que ses satellites (lien Ethernet, drapeau pont 802.1).
  • Il n'existe aucun réglage, ni dans l'interface ni dans l'API (même en cherchant les objets cachés), pour désactiver ce contrôleur EasyMesh. Couper le Wi-Fi de la box ne change rien : l'agent 1905 est accroché au pont LAN, pas aux radios.

Pourquoi c'est conçu comme ça (et pourquoi c'est un problème)
La Livebox est faite pour qu'un client branche un "Répéteur Wi-Fi 6" Orange sans rien configurer. Le contrôleur EasyMesh tourne donc en permanence, sans interrupteur, et l'interface prévoit même le cas "Wi-Fi de la box éteint, répéteurs allumés". Le présupposé est que tout agent 1905 vu sur le câble est un répéteur Orange. La box ne filtre ni par constructeur ni par certification. Avec un mesh tiers certifié EasyMesh (Orbi, mais aussi Deco, certains Cudy, etc.), on se retrouve avec deux contrôleurs sur le même réseau, et la box se laisse déclarer voisine par les satellites d'un mesh qui n'est pas le sien, en boucle.

Ce que je ne prétends pas
La tempête de topologie a le même débit avec ou sans fuite (elle tourne aussi pendant les 46 h de calme). Elle n'est donc pas, à elle seule, la cause de la fuite. Mon hypothèse est que la fuite est dans le même composant (gestion topologie / appareils) et qu'elle est déclenchée par le va-et-vient des clients Apple entre les nœuds du mesh, tel que rapporté par le 1905. Je vais le tester en supprimant physiquement les trames 1905 (point d'accès sans EasyMesh, puis switch manageable avec ACL sur l'EtherType 0x893A entre box et Orbi). Je posterai le résultat ici.

Mes questions
  • Qui a une Livebox 7 (ou 6) avec un mesh tiers (Orbi, Deco, eero, Google, Cudy...) et des reboots "Oops" ou des gels à intervalle régulier ? Et à l'inverse, qui a un mesh tiers et zéro problème ? Le modèle et le mode (routeur ou point d'accès) m'intéressent.
  • Quelqu'un connaît-il un moyen de désactiver le contrôleur EasyMesh / 1905 de la Livebox 7 ?
  • Un retour d'Orange ou de Sagemcom sur ce firmware ? J'ai un dossier complet (courbes mémoire, historique de boots, table de voisins 1905) prêt à être transmis à l'expert Orange, je peux le partager... mais le sav niveau 1 a escaladé chez orange... j'attend sque orange me contacte ... à voir si ils ne ferton, en attendant ma box plante environ toutes les 2 à 3 heures...

Merci d'avance.
Pages: 1 2 3 4 [5] 6 7 8 9 10