Re: Quelques applis bloquée sur un lien 4G [RESOLU]

Bonjour,

Sur une autre liste, plusieurs personnes m'ont indiqué que le pb que je rencontrait provenait probablement d'un pb de MTU.

L'adresse www.google.com étant résolue en 64.233.166.104, j'ai saisi les commandes :
#ping -c1 -M do -s 1272 64.233.166.104
PING 64.233.166.104 (64.233.166.104) 1272(1300) bytes of data.
72 bytes from 64.233.166.104: icmp_req=1 ttl=41 (truncated)

--- 64.233.166.104 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 52.260/52.260/52.260/0.000 ms
# ping -c1 -M do -s 1273 64.233.166.104
PING 64.233.166.104 (64.233.166.104) 1273(1301) bytes of data.

--- 64.233.166.104 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

J'en ai déduis que le MTU était de 1272+28=1300 sur un lien 4G Bouygues.

En appliquant bestialement, la commande ci-après, les commandes qui échouaient, ont fonctionné.

ip link set eth0 mtu 1300

J'ai passé beaucoup de temps, pour monter dans mon labo, une plate-forme reproduisant le pb.

Je n'ai pas réussi à reproduire le pb.

Le lien [1] suggère que le pb est peut être lié à un firewall qui écarte les paquets fragmentés.

Comme ma plate-forme de test ne comportant pas de firewall, ceci explique peut-être pourquoi je n'arrive pas à reproduire le pb.

[1] http://www.snailbook.com/faq/mtu-mismatch.auto.html

Merci à tous pour vos aides.

Le 4 mars 2016 à 07:13, Josh <josh@pas-cuit.net> a écrit :

On 03/03/2016 17:51, Olivier wrote:
> En anticipant que l'origine du blocage serait un MTU incorrect, j'ai
> cherché à déterminer celui-ci avant la commande ci-après:
> ping -c1 -M do -s 1272 194.158.122.10
> où 194.158.122.10 est l'adresse du serveur DNS de Bouygues.
>
> Au delà de 1272, j'ai:
> PING 194.158.122.10 (194.158.122.10) 1273(1301) bytes of data.
>
> --- 194.158.122.10 ping statistics ---
> 1 packets transmitted, 0 received, 100% packet loss, time 0ms
>
>
>
> Avec 1272 et en deçà, j'ai:
> PING 194.158.122.10 (194.158.122.10) 1272(1300) bytes of data.
> 1280 bytes from 194.158.122.10: icmp_req=1 ttl=244 time=55.1 ms
>
> --- 194.158.122.10 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 55.123/55.123/55.123/0.000 ms
>
>
> Que penser de tout ça ?
>
> Le 3 mars 2016 à 16:37, Olivier <oza.4h07@gmail.com> a écrit :
>

Lu,

Que c'est très moche de ne pas renvoyer le paquet icmp erreur
"fragmentation needed and DF set" ? :-)
Pourquoi, je n'en sais rien par contre. Bonne question ?
A moins que ça vienne de chez toi/que tu filtres icmp ?

Il faut aller voir du coté des options --mssfix et --fragment d'open-vpn
pour l'empêcher de transmettre des paquets qui seraient supérieur au mtu
du/des routeurs qui posent soucis (en restant abusivement silencieux, ne
lui permettant pas de découvrir le mtu max et d'ajuster ses datagrams
udp en fonction de celui ci).

--mssfix devrait être particulièrement utile pour ssh (et tcp en général).

Sinon, éventuellement passer open-vpn sur tcp à la place d'udp.

--
Josh