Auteur Sujet: Orange/SOSH bloque les mises à niveau et les mises à jour de Linux Mint (Lu 237 fois)

InfoLibre · « **le:** **Hier** à 17:23:36 »

Si vous êtes client(e) d'Orange/SOSH, vous avez peut-être du mal à mettre à niveau ou à mettre à jour Linux Mint.
https://communaute.orange.fr/t5/espace-de-convivialit%C3%A9/Probl%C3%A8me-de-mise-%C3%A0-jour-Linux-Mint/m-p/3339121
Si une bonne âme d'Orange passe ici et peut résoudre cela...

vivien · « **Réponse #1 le:** **Hier** à 17:36:00 »

Pour Orange mobile (j'ai une box 5G Orange), cela semble ok en IPv6 :

http://packages.linuxmint.com/ s'affiche bien dans mon navigateur. Si c'était un problème de routage, je ne devrais pas voir la page web.

Par contre j'ai des pertes de paquets sur la cible.

Traceroute:

$ mtr -zrwc100 packages.linuxmint.com Start: 2025-10-06T17:32:18+0200 HOST: HP Loss% Snt Last Avg Best Wrst StDev 1. AS3215 flybox.home 0.0% 100 2.6 1.5 0.9 3.4 0.4 2. AS3215 2a01cb09b050939500000058a44db740.ipv6.abo.wanadoo.fr 0.0% 100 35.3 28.3 15.4 83.2 7.9 3. AS??? ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0 4. AS??? 2a01:cd00:1ef:101::10 0.0% 100 32.0 29.5 11.7 87.3 11.1 5. AS??? 2a01:cd00:1ef:99::49 0.0% 100 34.0 25.7 9.7 89.4 11.0 6. AS??? 2a01:cd00:1ef:99::54 0.0% 100 16.5 28.0 10.9 91.8 11.0 7. AS??? 2a01:cd00:1ef:12::62 0.0% 100 19.2 26.2 9.5 93.7 10.3 8. AS??? 64:ff9b::a64:1241 0.0% 100 27.8 26.9 11.1 96.1 9.6 9. AS??? 64:ff9b::51fd:b8e2 0.0% 100 25.0 29.4 9.3 101.6 10.3 10. AS??? 64:ff9b::c1fb:6ee9 0.0% 100 50.3 31.6 15.3 73.6 8.8 11. AS??? ? ? 100.0 100 12. AS??? ? ? 100.0 100 13. AS??? 64:ff9b::c1fb:8308 2.0% 100 17.5 68.7 13.3 489.6 107.7 14. AS??? ? ? 100.0 100 15. AS??? 64:ff9b::5474:86c5 0.0% 100 174.1 172.4 155.9 201.7 8.5 16. AS??? ? ? 100.0 100 17. AS??? 64:ff9b::5474:8caa 0.0% 100 178.5 176.5 159.6 219.5 9.7 18. AS??? 64:ff9b::5474:928e 0.0% 100 146.2 144.2 128.2 280.8 17.5 19. AS??? 64:ff9b::5474:9291 0.0% 100 198.8 175.0 155.6 346.2 20.8 20. AS??? 64:ff9b::d52e:a71a 0.0% 100 119.9 129.4 115.6 170.3 8.4 21. AS??? ? ? 100.0 100 22. AS??? ? ? 100.0 100 23. AS??? ? ? 100.0 100 24. AS??? ? ? 100.0 100 25. AS??? ? ? 100.0 100 26. AS??? ? ? 100.0 100 27. AS??? 64:ff9b::d04d:140b 82.0% 100 135.4 132.1 123.7 139.7 5.1

InfoLibre · « **Réponse #2 le:** **Hier** à 17:46:05 »

Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. livebox.home 0.0% 222 0.6 0.4 0.3 1.7 0.1
2. 80.10.235.229 0.0% 222 2.4 2.1 1.8 8.3 0.6
3. lag-10.nemets1z.rbci.orange.net 0.0% 222 2.1 2.1 1.8 6.9 0.4
4. ae123-0.ncncy202.rbci.orange.net 0.0% 222 4.2 5.0 2.5 77.2 8.3
5. ae42-0.nistr102.rbci.orange.net 0.0% 222 6.6 6.3 5.9 10.9 0.6
6. (waiting for reply)
7. 193.251.131.8 0.5% 221 15.0 33.8 15.0 401.0 72.8
8. (waiting for reply)
9. fr-par02b-rd1-ae-3-0.aorta.net 0.0% 221 151.6 151.8 151.2 170.1 2.1
10. (waiting for reply)
11. us-nyc01b-rd2-ae-9-0.aorta.net 0.0% 221 217.4 153.4 150.9 298.7 15.6
12. us-was03a-rd1-ae-5-0.aorta.net 0.0% 221 121.2 121.5 120.4 190.6 5.4
13. us-chi01a-ri3-ae-9-0.aorta.net 0.0% 221 151.7 153.5 150.8 330.6 14.6
14. 213.46.167.26 0.0% 221 117.0 116.9 116.6 120.9 0.4
15. (waiting for reply)
16. mx.sygnow.net 93.6% 221 116.3 116.6 116.3 117.5 0.3

kgersen · « **Réponse #3 le:** **Hier** à 17:54:27 »

J'ai 200Mbs depuis une ligne Orange fibre mais bien plus en multi (environ 700 Mbps)

Code: [Sélectionner]

./nspeed get  http://packages.linuxmint.com/pool/upstream/c/chromium/chromium_126.0.6478.126~linuxmint1%2Bfaye_i386.deb 
190.7 Mbps
./nspeed get -n 4  http://packages.linuxmint.com/pool/upstream/c/chromium/chromium_126.0.6478.126~linuxmint1%2Bfaye_i386.deb
757.7 Mbps

ce n'est pas du au fait que c'est en HTTP et pas HTTPS ? certains PC interceptent le trafic http non chiffré ...

apres le serveur est a Chicago avec un peering moyen depuis Orange.

@vivien ce n'est pas de l'IPv6 natif mais du NAT64 que tu fais la. La cible n'a pas d'IPv6.

vivien · « **Réponse #4 le:** **Hier** à 17:57:48 »

Désolé, j'ai oublié que j'avais un DNS64.

Symbol · « **Réponse #5 le:** **Aujourd'hui** à 03:07:03 »

1) il y a deux IPs, donc n'indiquer que le hostname n'est pas pertinent:

Code: [Sélectionner]

% host packages.linuxmint.com
packages.linuxmint.com has address 208.77.20.11
packages.linuxmint.com has address 208.77.20.19

2) Depuis une livebox Orange, le ping ne ping pas tellement en effet, surtout la première IP. Mais enfin ça répond tout à fait au HTTP port 80:

Code: [Sélectionner]

% gtelnet 208.77.20.11 80
Trying 208.77.20.11...
Connected to 208.77.20.11.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: packages.linuxmint.com

HTTP/1.0 200 OK
Content-type: text/html; charset=UTF-8
Connection: close
Date: Tue, 07 Oct 2025 00:13:08 GMT
Server: Lighttpd

Connection closed by foreign host.

3) en revanche, pour avoir quelque chose de pertinent:

- depuis une machine quelconque hors Orange, pas de problème:

Code: [Sélectionner]

# telnet 208.77.20.11 80
Trying 208.77.20.11...
Connected to 208.77.20.11.
Escape character is '^]'.
GET / HTTP/1.1
Host: packages.linuxmint.com

HTTP/1.1 200 OK
Content-type: text/html; charset=UTF-8
Accept-Ranges: bytes
Content-Length: 23853
Date: Tue, 07 Oct 2025 00:15:29 GMT
Server: Lighttpd


<!doctype html>
<html lang="en">
     [ lots of stuff ]
</html>
Connection closed by foreign host.

- depuis une Livebox Orange, ça merde:

Code: [Sélectionner]

% gtelnet 208.77.20.11 80
Trying 208.77.20.11...
Connected to 208.77.20.11.
Escape character is '^]'.
GET / HTTP/1.0
Host: packages.linuxmint.com


     [ rienkeudal ]

Connection closed by foreign host.

Et une analyse du traf par un tcpdump quelconque nous dit que dans les paquets reçus, on passe de la sequence segment 1 à 15929 alors qu'on a reçu quedalle (au paquet 11):

Code: [Sélectionner]

    4   0.732963 192.168.1.19 → 208.77.20.11 TCP 56578 80 82 GET / HTTP/1.0 
    5   0.848694 208.77.20.11 → 192.168.1.19 TCP 80 56578 66 80 → 56578 [ACK] Seq=1 Ack=17 Win=65152 Len=0 TSval=3000395555 TSecr=3378398185
    6   1.046946 192.168.1.19 → 208.77.20.11 TCP 56578 80 96 GET / HTTP/1.0  [TCP PDU reassembled in 6]
    7   1.157012 208.77.20.11 → 192.168.1.19 TCP 80 56578 66 80 → 56578 [ACK] Seq=1 Ack=47 Win=65152 Len=0 TSval=3000395869 TSecr=3378398499
    8   1.321046 192.168.1.19 → 208.77.20.11 HTTP 56578 80 68 GET / HTTP/1.0 
    9   1.431368 208.77.20.11 → 192.168.1.19 TCP 80 56578 66 80 → 56578 [ACK] Seq=1 Ack=49 Win=65152 Len=0 TSval=3000396144 TSecr=3378398773
[ appuyons sur enter, car il ne se passe rien après le get, et on s'emmerde ]
   10   4.665227 192.168.1.19 → 208.77.20.11 HTTP 56578 80 68 Continuation
   11   4.816070 208.77.20.11 → 192.168.1.19 TCP 80 56578 66 [TCP Previous segment not captured] 80 → 56578 [ACK] Seq=15929 Ack=51 Win=65152 Len=0 TSval=3000399528 TSecr=3378402117
   12   7.760047 192.168.1.19 → 208.77.20.11 HTTP 56578 80 68 Continuation
   13   7.870692 208.77.20.11 → 192.168.1.19 TCP 80 56578 54 80 → 56578 [RST] Seq=1 Win=0 Len=0

Paquet 11: on est passé de la sequence 1 à 15929, alors qu'on n'a rien reçu du tout, donc on a des gros paquets qui ont été mangés quelque part.
On pense donc immédiatement à un problème de MTU à un endroit.

4) Faisons des pings (sur .19, car sur .11 ça répond pas des masses) avec des tailles de paquets croissantes:

Code: [Sélectionner]

PING 208.77.20.19 (208.77.20.19): 1468 data bytes
1476 bytes from 208.77.20.19: icmp_seq=0 ttl=53 time=109.641 ms

    1   0.000000 192.168.1.19 → 208.77.20.19 ICMP   1510 Echo (ping) request  id=0x4659, seq=0/0, ttl=64
    2   0.109299 208.77.20.19 → 192.168.1.19 ICMP   1510 Echo (ping) reply    id=0x4659, seq=0/0, ttl=53 (request in 1)


PING 208.77.20.19 (208.77.20.19): 1469 data bytes
1477 bytes from 208.77.20.19: icmp_seq=0 ttl=53 time=111.694 ms

    3   4.713645 192.168.1.19 → 208.77.20.19 ICMP   1511 Echo (ping) request  id=0x4759, seq=0/0, ttl=64
    4   4.824980 208.77.20.19 → 192.168.1.19 IPv4   1506 Fragmented IP protocol (proto=ICMP 1, off=0, ID=c0cb)
    5   4.824983 208.77.20.19 → 192.168.1.19 ICMP   52 Echo (ping) reply    id=0x4759, seq=0/0, ttl=53 (request in 3)

C'est la merde: on envoie un paquet de 1496 octets ça va, on envoie un paquet de 1497 octets (1469+20+8), la réponse arrive fragmentée, la MTU IP de la box en face vers nous est limitée à 1496, et comme par hasard on ne reçoit pas les grosses réponses HTTP.

Pourquoi avec Orange France spécialement, va savoir le merdier qu'il doit y avoir dans l'infra d'en face (et toutes les IPs adjacentes semblent avoir le même comportement).
On me dira, ça pourrait quand même marcher. Mais visiblement pas tellement

En tous cas depuis ailleurs, ça ping à 1472 (MTU 1500) sans fragments.

Alors, par où ça passe vers Orange (pour connaitre le trajet retour, qui nous intéresse)?
Ils ont bien un looking glass (https://www.tzulo.com/lg/): ça passe par RCN puis Level3LumenColt quand ça marche, ça passe apparemment par PCCW quand ça merde.

Un traceroute vers un client qui marche (vers TI Sparkle à la fin):

Code: [Sélectionner]

HOST: web1.tzulo.com                               Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- static-208-77-21-1.cust.tzulo.com             0.0%    10    0.4   0.5   0.4   1.0   0.2
2.|-- 208.77.17.2                                   0.0%    10    0.8   0.8   0.7   0.9   0.1
3.|-- 208.77.17.1                                   0.0%    10    0.9   0.8   0.6   0.9   0.1
4.|-- 216.80.40.173                                 0.0%    10    3.4   2.1   1.5   4.5   1.0
5.|-- ???                                          100.0    10    0.0   0.0   0.0   0.0   0.0
6.|-- hge0-0-0-12.edge1.ord-eqnx.il.bb.astound.net  0.0%    10    3.5   4.0   3.2   5.0   0.6
7.|-- lag-107.ear4.Chicago2.Level3.net             90.0%    10    1.7   1.7   1.7   1.7   0.0
8.|-- ae2.3610.edge1.Washington111.net.lumen.tech   0.0%    10   18.6  21.5  18.6  42.0   7.2
9.|-- 195.22.206.98                                 0.0%    10   17.6  21.7  17.4  32.2   6.0
[.....]

Un autre vers un client qui déconne chez Orange:

Code: [Sélectionner]

HOST: web1.tzulo.com                    Loss%   Snt   Last   Avg  Best  Wrst StDev
1.|-- static-208-77-21-1.cust.tzulo.com  0.0%    10    0.6   0.6   0.4   0.9   0.1
2.|-- 208.77.17.2                        0.0%    10    0.7   0.8   0.6   1.0   0.1
3.|-- 208.77.17.1                        0.0%    10    0.6   0.8   0.6   1.0   0.1
4.|-- 63.222.115.190                     0.0%    10    1.4   1.4   1.3   1.5   0.1
5.|-- BE41.br04.ash02.as3491.net        10.0%    10   20.9  20.9  20.8  21.5   0.2
6.|-- pos0-3.cr03.ash01.as3491.net       0.0%    10   20.3  20.5  20.3  20.7   0.1
7.|-- 81.52.166.172                      0.0%    10  105.3 107.9 105.2 130.8   8.1
8.|-- lag-1.niidf103.rbci.orange.net    70.0%    10  104.8 104.9 104.8 105.1   0.1

Il se fait que ça change au hop nº4. Une IP PCCW (qui peut sûrement d'ailleurs être portée par un équipement de Tzulo).
On peut le pinger.
En principe pinger un routeur en espérant un résultat utile est complètement débile.
Mais pour une fois:

Code: [Sélectionner]

% ping -c 2 -W 1000 -n -s 1468 63.222.115.190
PING 63.222.115.190 (63.222.115.190): 1468 data bytes
1476 bytes from 63.222.115.190: icmp_seq=0 ttl=248 time=102.185 ms
1476 bytes from 63.222.115.190: icmp_seq=1 ttl=248 time=101.891 ms

--- 63.222.115.190 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 101.891/102.038/102.185/0.147 ms



% ping -c 2 -W 1000 -n -s 1469 63.222.115.190
PING 63.222.115.190 (63.222.115.190): 1469 data bytes
Request timeout for icmp_seq 0

--- 63.222.115.190 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

Ça passe avec des paquets IP de 1496, ça coince au delà: un comportement étrangement similaire.

Ce looking glass a le mérite d'exister, mais on n'a pas les autres IPs lorsqu'il y a une résolution DNS. Toutefois, on note que le ping passe sur la première IP OpenTransit/Orange (interco PCCW/OpenTransit: 81.52.166.172) avec une MTU de 1500 sans fragmentation.

Bon, des paquets fragmentés ça peut passer, mais soit un routeur les fragmente et ne le fait que de temps en temps (mais avec PMTUd il n'est pas censé), soit il y a moult ICMP Must Fragment entre ledit routeur et les serveurs derrière (et ils sont ratelimités d'un côté comme de l'autre), soit les fragments sont ratelimités (il est classique de ratelimiter les fragments un peu partout: dans les fragments subséquents on ne peut plus identifier le protocole, et il n'y a plus guère que du DDoS volumétrique par amplification (NTP, DNS, Chargen, etc etc) qui utilise ça massivement sur Internet ; de nos jours on ne peut plus en attendre des perfs pertinentes), soit autre chose.

BREF: le problème me semble se situer à Chicago ou à Ashburn, chez Tzulo ou entre Tzulo et PCCW, mais sans rapport avec Orange.