Bon fausse joie,

Le support Orange m'envoie quelqu'un qui doit me faire du conseil (et me facturer) et qui va constater que la connection ne marche pas. Autrement dit je suis reparti pour un tour .

Il ne faut pas que le problème soit résolu avant que le gars constate le souci, sinon ça va être une grosse facture .

 :'(

Caeies.

Bah, moi je vais lui montrer que le ping ne passe pas donc ça marche pas.

Mais oui je crains fort que ça ne finisse au contentieux cette histoire .

Caeies,

Bon,

Bilan des courses, le gars qui devait prendre contact a été optimisé sur un autre planning et son remplaçant pas à la hauteur, n'a pas voulu ouvrir le ticket, il a juste demandé à relancer la chose (mais sur un ticket qui n'existe pas ?).

D'après lui le 3900 doit me rappeler, mais j'ai du mal à y croire. J'essaierai d'appeler demain, on verra.

Je sens qu'il va falloir que je garde mon calme.

Merci a Petrus pour sa tentative, peut être qu'avec un peu de chance elle aboutira :/.

Pour info et pour être complet :

Il faut: -s 13+$(($N*16)) avec N > 0, et -p $k$j avec k ∈ [0,3]∪[8,b] et j ∈ [8,f].

Vérifiable simplement avec le ping unix (quelque soit l'orde des valeurs testés):

for k in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do { if ! ping -q -4 -w 1 -n -c 1 -p $k$j -s 29 appliwave.iperf.fr > /dev/null; then echo "$k$j dropped"; fi }; done; done;
Qui donne chez moi :
08 dropped
09 dropped
0a dropped
0b dropped
0c dropped
0d dropped
0e dropped
0f dropped
18 dropped
19 dropped
1a dropped
1b dropped
1c dropped
1d dropped
1e dropped
1f dropped
28 dropped
29 dropped
2a dropped
2b dropped
2c dropped
2d dropped
2e dropped
2f dropped
38 dropped
39 dropped
3a dropped
3b dropped
3c dropped
3d dropped
3e dropped
3f dropped
88 dropped
89 dropped
8a dropped
8b dropped
8c dropped
8d dropped
8e dropped
8f dropped
98 dropped
99 dropped
9a dropped
9b dropped
9c dropped
9d dropped
9e dropped
9f dropped
a8 dropped
a9 dropped
aa dropped
ab dropped
ac dropped
ad dropped
ae dropped
af dropped
b8 dropped
b9 dropped
ba dropped
bb dropped
bc dropped
bd dropped
be dropped
bf dropped

Au besoin, je peux filer un bout de code c# pour windows pour faire la même chose (je suis pas expert c#, donc le code est un copié collé du site de microsoft sur le sujet, modifé pour faire le taff): (ne marche pas avec mono sous linux car il ne passe pas les bons params au ping).

cat ping.cs
using System;
using System.Net;
using System.Net.NetworkInformation;
using System.Text;

namespace Examples.System.Net.NetworkInformation.PingTest
{
    public class PingExample
    {
        // args[0] can be an IPaddress or host name.
        public static void Main (string[] args)
        {
            Ping pingSender = new Ping ();
            PingOptions options = new PingOptions ();

            // Use the default Ttl value which is 128,
            // but change the fragmentation behavior.
            options.DontFragment = true;

            char pattern = '\x0f'; // you can choose any value $k$j with k ∈ [0,3]∪[8,b] et j ∈ [8,f]
            for (int i = 13; i < 13+5*16; i++)
            {
            string data = new string(pattern, i);
            byte[] buffer = Encoding.ASCII.GetBytes (data);
            int timeout = 120;
            PingReply reply = pingSender.Send (args[0], timeout, buffer, options);
            if (reply.Status == IPStatus.Success)
            {
                //Console.WriteLine ("Address: {0}", reply.Address.ToString ());
                //Console.WriteLine ("RoundTrip time: {0}", reply.RoundtripTime);
                //Console.WriteLine ("Time to live: {0}", reply.Options.Ttl);
                //Console.WriteLine ("Don't fragment: {0}", reply.Options.DontFragment);
                //Console.WriteLine ("Buffer size: {0}", reply.Buffer.Length);
            }
            else
           {
               Console.WriteLine ("Dropped with Buffer size: {0}", buffer.Length);
            }
            }
        }
    }
}

Qui a dit que windows était network ready ? 

Caeies,

Salut Hwti,

Il manque un sleep, sinon ça envoie des pings trop rapprochés et la Livebox ne répond pas toujours.

Ouais, j'ai testé avec un sleep c'est pareil ... et non réponse sur 3 ping de suite .... ça saute de temps en temps, normal, mais si tu prends chaque ping généré ça explose à la main aussi. J'avoue que plein de monde me dit que si on ping trop, la livebox drop, ben pour l'instant j'ai pas constaté ça dans les faits.

pour preuve:
for j in 0 1 2 3 4 5 6 7 8 9 a b c d e f; do for i in $(seq 3 3); do { echo -n "$j $i "; ping -n -w1 -c 1 -t$i -p 0000000000000000001$j -s 173 ping.online.net | grep icmp_seq; }; done; echo; sleep 0.1; done
0 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

1 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

2 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

3 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

4 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

5 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

6 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

7 3 From 193.253.80.250 icmp_seq=1 Time to live exceeded

8 3
9 3
a 3
b 3
c 3
d 3
e 3
f 3


Que les paquets sortent bien de la Livebox, et comme le serveur les redemande tu en déduis que le réseau les a perdus ?

Non le serveur ne redemande pas, il ne les acks pas, et continue d'envoyer d'autres paquets tcp sans faire les ack du paquet retransmis. Donc oui j'en déduis qu'en plus du ping, il drop des paquets tcp sur la ligne (car le routage n'est pas le même en sortie et en retour).

Il me semble que j'ai mis les traces de l'extérieur de mon réseau (via l'airbox) sur le thread, je trouve ça très parlant.

On est d'accord, la livebox fait le nat et pourrait se tromper dans le calcul des CHCK ... on parle de linux tout de même qui marche très bien pour le reste du monde. ou alors le chksum est calculé dans la carte réseau elle-même et borké ici: 2 livebox seraient HS chez moi et fonctionnelles chez d'autres ... j'ai du mal à y croire aussi (surtout que j'ai eu deux versions différentes de livebox 4, et deux versions différentes d'ONT).

De mémoire, lorsque j'ai fait la capture wireshark entre la livebox et l'ONT je n'ai pas vu d'erreur de checksum sur les paquets qui sortaient. (surtout que dans wireshark c'est en gros et en noir, ça se rate difficilement). MAIS comme ce sont des retransmits, je peux pas exclure de ne pas y avoir prêté attention. Je revérifierais.

Je viens de vérfier pourquoi mon 16 échoue à chaque fois sur la livebox, et il y a bien un rate limiting sur certains messages ICMP émis par la livebox (comme te ttl exceeded). Mais clairement pas dans les transmissions:

sudo ping -n -f -s 29 -c 100 -p 00 ping.online.net
PATTERN: 0x00
PING ping.online.net (62.210.18.40) 29(57) bytes of data.
 
--- ping.online.net ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 299ms
rtt min/avg/max/mdev = 2.799/2.939/4.737/0.187 ms, ipg/ewma 3.019/2.980 ms

sudo ping -n -w1 -f -s 29 -c 10 -p 0f ping.online.net
PATTERN: 0x0f
PING ping.online.net (62.210.18.40) 29(57) bytes of data.
..............................................................
--- ping.online.net ping statistics ---
62 packets transmitted, 0 received, 100% packet loss, time 992ms


Caeies,

PS: rien que pour se post, il a fallu que je tente 3 fois avant qu'il passe .

J'avoue que plein de monde me dit que si on ping trop, la livebox drop, ben pour l'instant j'ai pas constaté ça dans les faits.

Sans sleep sur le test j'ai quelques fois où la Livebox ne répond pas, mais les routeurs derrières si (donc c'est juste une limite de fréquence d'émission de TTL exceeded par la Livebox).

Il me semble que j'ai mis les traces de l'extérieur de mon réseau (via l'airbox) sur le thread, je trouve ça très parlant.

Je n'ai pas vu de capture, juste les tests avec ping et iperf.

On est d'accord, la livebox fait le nat et pourrait se tromper dans le calcul des CHCK ... on parle de linux tout de même qui marche très bien pour le reste du monde. ou alors le chksum est calculé dans la carte réseau elle-même et borké ici: 2 livebox serait HS chez moi et fonctionnelles chez d'autres ... j'ai du mal à y croire aussi (surtout que j'ai eu deux versions différentes de livebox 4, et deux versions différentes d'ONT)

Sur les box, il y a deux chemins possibles :
 - via Linux de manière classique pour les premiers paquets (avec probablement les offloads du contrôleur pour les checksums)
 - via le NAT HW, une fois le flux établi (les checksums sont donc gérés par l'accélérateur)

Il pourrait y avoir des bugs, peut-être uniquement sur certaines versions de firmware.
Mais je ne vois pas pourquoi ça t'affecterait spécifiquement.

J'ai eu des problèmes de pertes de paquets en download, mais je n'ai pas eu le temps de les caractériser (je n'ai pas pensé à un lien possible avec la taille), maintenant c'est corrigé.

De mémoire, lorsque j'ai fait la capture wireshark entre la livebox et l'ONT je n'ai pas vu d'erreur de checksum sur les paquets qui sortaient. (surtout que dans wireshark c'est en gros et en noir, ça se rate difficilement). MAIS comme ce sont des retransmits, je peux pas exclure de ne pas y avoir prêté attention. Je revérifierais.

Je ne suis pas sûr que Wirehark vérifie les checksums dans tous les cas.
Il y a au moins le cas de la capture locale, où il est ignoré pour les paquets émis.
De même si les paquets sont combinés ou découpés par la carte ou le driver (TSO, GRO, ...), Wireshark ne voit pas les paquets réels.

Tous,

Suite des tribulations: Un ticket Oceane à bien été ouvert chez Orange ... maintenant il faut être .... «patient».

Pour hwti:

Via mon Airbox, voila ce que ça donne:

for i in $(seq 1 18); do { echo -n "$i "; ping -n -c 1 -t$i -p 0f -s 29 -w1 90.127.xx.yy| grep icmp_seq; }; sleep 1; done
1 From 192.168.1.1: icmp_seq=1 Time to live exceeded
2 From 10.68.211.64: icmp_seq=1 Time to live exceeded
3 From 10.68.210.49: icmp_seq=1 Time to live exceeded
4 From 10.68.210.54: icmp_seq=1 Time to live exceeded
5 From 10.68.210.62: icmp_seq=1 Time to live exceeded
6 From 10.68.210.65: icmp_seq=1 Time to live exceeded
7 From 193.252.137.34: icmp_seq=1 Time to live exceeded
8 From 193.251.110.209: icmp_seq=1 Time to live exceeded
9 From 193.252.98.145: icmp_seq=1 Time to live exceeded
10 From 193.251.126.102: icmp_seq=1 Time to live exceeded
11 From 193.252.98.93: icmp_seq=1 Time to live exceeded
12 From 193.253.80.249: icmp_seq=1 Time to live exceeded
13 From 90.127.xx.yy: icmp_seq=1 Time to live exceeded #<= c'est la preuve que le paquet arrive à la livebox car il passe par 80.249)
14 15 16 17 18


$ for i in $(seq 1 18); do { echo -n "$i "; ping -n -c 1 -t$i -p 00 -s 29 -w1 90.127.xx.yy | grep icmp_seq; }; sleep 1; done
1 From 192.168.1.1: icmp_seq=1 Time to live exceeded
2 From 10.68.211.64: icmp_seq=1 Time to live exceeded
3 From 10.68.210.49: icmp_seq=1 Time to live exceeded
4 From 10.68.210.54: icmp_seq=1 Time to live exceeded
5 From 10.68.210.62: icmp_seq=1 Time to live exceeded
6 From 10.68.210.65: icmp_seq=1 Time to live exceeded
7 From 193.252.137.34: icmp_seq=1 Time to live exceeded
8 From 193.251.110.209: icmp_seq=1 Time to live exceeded
9 From 193.252.98.145: icmp_seq=1 Time to live exceeded
10 From 193.251.126.102: icmp_seq=1 Time to live exceeded
11 From 193.252.98.93: icmp_seq=1 Time to live exceeded
12 From 193.253.80.249: icmp_seq=1 Time to live exceeded
13 From 90.127.xx.yy icmp_seq=1 Time to live exceeded
14 37 bytes from 90.127.xx.yy icmp_seq=1 ttl=50 time=53.3 ms # le paquet revient par 80.10.236.81 puis 193.253.80.250
15 37 bytes from 90.127.xx.yyicmp_seq=1 ttl=50 time=47.9 ms
16 37 bytes from 90.127.xx.yy icmp_seq=1 ttl=50 time=47.1 ms
17 37 bytes from 90.127.xx.yy icmp_seq=1 ttl=50 time=53.7 ms
18 37 bytes from 90.127.xx.yy: icmp_seq=1 ttl=50 time=49.8 ms
Je regarde pour la suite ce WE.

Cordialement,