Messages récents

Pages: 1 [2] 3 4 5 6 7 ... 10
11
Free Mobile Incidents Free Mobile / Panne générale sur Rennes !
« Dernier message par Fuzy le Aujourd'hui à 15:43:11 »
Oui 16 septembre, ça fait peur !

L'ensemble HS :

https://mobile.free.fr/pannes-antennes-relais

https://www.free-reseau.fr/incidents-du-jour/#cdf35-FTTH

Les ados chez free vont péter un plomb !!!!

12
Câblage Câblage / Projet stupide du moment : le 10G dans toutes les pièces !
« Dernier message par Kana-chan le Aujourd'hui à 15:16:04 »
Attention, il faut toujours séparer les câbles électriques (EDF) des autres (télécom et fibre dans une moindre mesure) !
13
Orange fibre Incidents Orange / Cherche mail de bienvenue Orange de 2018
« Dernier message par loutre3 le Aujourd'hui à 15:15:34 »
3822.

14
Free Mobile Incidents Free Mobile / Panne générale sur Rennes !
« Dernier message par fansat70 le Aujourd'hui à 15:09:43 »
Sur la carte des antennes Free en panne, au moins un groupe de 4 antennes étaient signalées en panne (ou maintenance) sur l'Ouest de Rennes, avec une antenne sur Saint Jacques de la Lande. La durée de la "panne" (ou maintenance) est indiquée jusqu'au 16 Septembre (Par précaution j'espère!). J'ai du monde qui bosse à Rennes, là!
15
Oui, ça fait la meme chose malheureusement
16

    Option: (77) User Class Information
        Length: 42
        User Class Data (Text): +FSVDSL_livebox.Internet.sagem.LiveboxPro3
   


Peux-tu reesayer avec la valeur de Livebox 7 (au lieu de LiveboxPro3) ?
17
Ca marche plus avec leur RASH2 sur cette chaine. Faut juste passer par l'appli myCanal est OK

18
Bonjour à tous,

Je me permet de répondre car j'ai rencontré moi aussi un problème de lag après avoir passé la box en mode bridge, j'ai réussi à résoudre le problème donc si ça peut servir...

Voici ma config :

Box : Freebox POP en mode bridge
Firewall/Routeur : Appliance OPNsense hardware (6x2,5G)
AP : TP-Link OMADA EAP650
DNS/DNCP : Technitium

Le player est connecté en WiFi sur l'AP, l'AP est connecté sur une interface de mon firewall, la Freebox est sur l'interface WAN.

---

Dans la config IPv6 de la box, j'ai renseigné dans chaque Next-Hop secondaire l'adresse link-local (fe80::...) de l'interface WAN de mon firewall pour chaque préfixe /64 utilisé derrière le routeur (un par VLAN que j'utilise). C'est ce qui permet à la Freebox de router le trafic retour vers les clients. Sans ça, les paquets IPv6 retour sont droppés silencieusement par la Freebox. C'est déjà bien expliqué plus haut.

J'ai un enregistrement AAAA dans mon DNS interne (Technitium) qui fait pointer mafreebox.freebox.fr vers la GUA de la box (2a01:___::1). En mode bridge, la box n'est plus accessible via son adresse ULA (fd0f:ee:b0::1) - cette adresse est injoignable une fois le mode bridge activé

Pour ceux qui sont sur OPNsense : j'ai déclaré une gateway IPv6 dans System > Gateways pointant vers l'adresse link-local de la Freebox (fe80::...) sur l'interface WAN, et je l'ai définie comme gateway par défaut IPv6. Sans cette étape, OPNsense n'a pas de route par défaut IPv6 et tout le trafic IPv6 vers Internet est droppé localement.

Analyse du lag
Avant l'ajout de l'entrée DNS : latence de +/- 10 secondes. Après l'ajout : +/- 3/4 secondes. J'ai fait des captures Wireshark pour éliminer le délai restant. Voici la séquence exacte observée :

  • Le player envoie une requête DNS AAAA pour mafreebox.freebox.fr afin d'obtenir l'adresse IPv6 de la box - c'est l'étape d'authentification réseau Free
  • Le player tente une connexion TCP vers la box sur le port RTSP 554 - c'est un vestige du protocole historique Free TV (les chaînes étaient autrefois distribuées en multicast IPTV directement depuis la box). En mode bridge, la box ne sert plus de contenu vidéo et ne répond pas sur ce port en IPv6
  • ~1 seconde plus tard, pas de réponse : le player envoie une retransmission TCP
  • ~2 secondes plus tard : le firewall renvoie un ICMPv6 "Destination Unreachable" signalant que la connexion RTSP est impossible
  • Le player abandonne la tentative RTSP et enchaîne sur les connexions OQEE
  • Requêtes DNS sur license.oqee.net et api.oqee.net - le player obtient des enregistrements A et AAAA pour ces serveurs
  • Connexion HTTPS vers api.oqee.net (2a01:e0f:1:9000::67) - récupération du manifeste de la chaîne et du token d'accès
  • Requête DNS sur time.akamai.com - synchronisation horaire, nécessaire pour la validation des tokens DRM et la synchronisation des flux live
  • Le player initie le streaming vers 2a01:e00:0:ffff::f5 - une adresse Anycast du réseau CDN Free/Proxad (2a01:e00::/32). Certains segments transitent également par Akamai (2a02:26f0::/32), un CDN tiers utilisé par Free pour la distribution de contenu. Le player n'obtient pas cette adresse via DNS - c'est le serveur api.oqee.net qui la fournit dans la réponse du manifeste (HLS/DASH). Le trafic est routé vers le point de présence Free le plus proche
  • La vidéo est lancée

Le fix final
Le délai résiduel de 3-4 secondes vient des étapes 2-4 : le player attend la réponse RTSP qui ne viendra jamais. La solution est d'ajouter une règle Reject (pas Block) sur le firewall pour le port 554 vers la box :

Reject | IPv6 | TCP | LAN net IPv6 | IP_GUA_Freebox | port 554

La distinction Block vs Reject est capitale : Block droppe le paquet silencieusement et le player attend le timeout TCP complet (~3 secondes). Reject envoie immédiatement un TCP RST, le player comprend instantanément que ce port n'est pas disponible et passe à l'étape suivante en quelques millisecondes.

Résultat : le lag restant disparaît complètement

Voilà, si comme moi certains observent toujours des lags même avoir fait une entrée DNS pour mafreebox.freebox.fr, j'espère que ce pourra servir.

Bonne journée

Et avec tous cela tu as accès à canal + live ?
Merci pour ta réponse car j'ai pas envi de tout casser ma config si ça ne fonctionne pas.
19
Pour le moment je me limite a l'ipv4 histoire de limiter les soucis potentiel.

J'ai fait une capture de trame, aucune réponse au Discover, donc je suis ignoré.
Je vois bien le 802.1Q sur le vlan 832 et la COS à 6.

je vois une option 55 non paramétrée de mon coté mais ça me parait pas déconnant.
L'option 61, 77 et 90 sont ok.

Ethernet II, Src: SagemcomBroa_e9:a0:10 (2c:f2:a5:e9:a0:10), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: SagemcomBroa_xx:xx:xx (2c:f2:a5:xx:xx:xx)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: 802.1Q Virtual LAN (0x8100)
    [Stream index: 3]
802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
    110. .... .... .... = Priority: Internetwork Control (6)
    ...0 .... .... .... = DEI: Ineligible
    .... 0011 0100 0000 = ID: 832
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 424
    Identification: 0x0000 (0)
    000. .... = Flags: 0x0
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 16
    Protocol: UDP (17)
    Header Checksum: 0xa946 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 0.0.0.0
    Destination Address: 255.255.255.255
    [Stream index: 1]
User Datagram Protocol, Src Port: 68, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0x45d55e48
    Seconds elapsed: 60
    Bootp flags: 0x0000 (Unicast)
    Client IP address: 0.0.0.0
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: SagemcomBroa_xx:xx:xx (2c:f2:a5:xx:xx:xx)
    Client hardware address padding: 00000000000000000000
    Server host name not given
    Boot file name not given
    Magic cookie: DHCP
    Option: (53) DHCP Message Type (Discover)
        Length: 1
        DHCP: Discover (1)
    Option: (55) Parameter Request List
        Length: 9
        Parameter Request List Item: (1) Subnet Mask
        Parameter Request List Item: (121) Classless Static Route
        Parameter Request List Item: (3) Router
        Parameter Request List Item: (33) Static Route
        Parameter Request List Item: (6) Domain Name Server
        Parameter Request List Item: (42) Network Time Protocol Servers
        Parameter Request List Item: (138) CAPWAP Access Controllers
        Parameter Request List Item: (43) Vendor-Specific Information
        Parameter Request List Item: (15) Domain Name
    Option: (60) Vendor class identifier
        Length: 5
        Vendor class identifier: sagem
    Option: (61) Client identifier
        Length: 7
        Hardware type: Ethernet (0x01)
        Client MAC address: SagemcomBroa_xx:xx:xx (2c:f2:a5:xx:xx:xx)
    Option: (77) User Class Information
        Length: 42
        User Class Data (Text): +FSVDSL_livebox.Internet.sagem.LiveboxPro3
    Option: (90) Authentication
        Length: 70
        Protocol: configuration token (0)
        Algorithm: 0
        Replay Detection Method: Monotonically-increasing counter (0)
        RDM Replay Detection Value: 0x0000000000000000
        Authentication Information: \x1A\t
    Option: (255) End
        Option End: 255

Par contre je vois que tu utilises des mangle et non les filtres, mais bon vu qu'à priori j'ai qd meme les bonnes valeurs..
20
Free Mobile Incidents Free Mobile / Panne générale sur Rennes !
« Dernier message par Fuzy le Aujourd'hui à 14:01:35 »
Pour information :
LTE et Fixe en Panne sur Rennes intra périphérique !

Edit :

https://www.ouest-france.fr/high-tech/internet/une-grosse-panne-de-free-a-rennes-des-milliers-de-clients-sans-internet-ni-telephone-4b24862a-ac36-11f1-8346-c9d5c99462af

https://www.free-reseau.fr/incidents-du-jour/#cdf35-FTTH

Ce qui est intriguant, c'est qu'il y a eu le même type de panne sur la commune Le Rheu (Rennes métropole) la semaine dernière (12h de panne totale).


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