Discussion :

[Obsidian]

- l'inclure de quel maniere ?

Encore une remarque : tu peux utiliser le bouton « Citer » d'un message pour reprendre le commentaire de quelqu'un. Il sera encadré par les balises [quote] et [/quote]. Mais dans ce cas, je t'incite fortement à l'éditer pour ne conserver que la phrase qui t'intéresse.

Tu peux également faire un copier-coller comme tu le fais déjà mais, dans ce cas, ajoute les balises en question, soit à la main, soit en utilisant le bouton de l'éditeur.

ou inclure un char dans ma structure icmp et faire le remplissage avec les bits de mon data vers le char ?

Oui, c'est cette seconde solution qui est la plus propre.

À noter toutefois que ta structure, telle que tu la définis actuellement (avec ou sans les datas, d'ailleurs), correspond aux messages « Echo » ou « Echo Reply » en particulier et pas à l'ICMP en général.

Important : c'est un tableau de char que tu dois définir dans ta structure, pour qu'elle contienne les données elle-mêmes et pas un pointeur vers elle. Tu dois donc en définir la taille exacte.

[Shark9]

voila probleme resolu merci de votre aide a tous , bien spécifique le checksum du protocol icmp enfin par rapport a entete IP etc etc .

pour le protocol TCP je suppose que le checksum se calcule en prenant en compte aussi les données a transmettre ?

[Obsidian]

Obsidian >> Ok, j'ai compris le principe. Le titre de la RFc est un peu confu donc et prête à mauvaise interprétation.

Ben pas vraiment, en fait : « Computing the Internet checksum », c'est relativement clair. Le vrai problème, c'est que lorsque l'on est pas natif de la langue anglaise, les mots « Adjacent octets to be checksummed are paired to form 16-bit integers, and the 1's complement sum of these 16-bit integers is formed. » sont très facilement interprétés de travers. Cela signifie précisément :

Les octets adjacents sont regroupés par paires pour former des entiers de 16 bits, et la somme en complément à 1 de ces entiers de 16 bits est formée »

… ce qui est complètement différent du « complément à 1 de la somme » qui est pourtant calculé à l'étape qui suit, et encore plus de « la somme des compléments à 1 des entiers ».

Et c'est important parce qu'on ne compte plus les tutoriaux amateurs sur le Net qui font cette erreur.

voila probleme resolu merci de votre aide a tous , bien spécifique le checksum du protocol icmp enfin par rapport a entete IP etc etc .

pour le protocol TCP je suppose que le checksum se calcule en prenant en compte aussi les données a transmettre ?

Non, c'est pire que cela, mais il t'appartient d'aller lire la RFC, désormais : http://tools.ietf.org/html/rfc761

Code RFC :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
[Page 16]
January 1980
                                           Transmission Control Protocol
                                                Functional Specification

  Checksum:  16 bits

    The checksum field is the 16 bit one's complement of the one's
    complement sum of all 16 bit words in the header and text.  If a
    segment contains an odd number of header and text octets to be
    checksummed, the last octet is padded on the right with zeros to
    form a 16 bit word for checksum purposes.  The pad is not
    transmitted as part of the segment.  While computing the checksum,
    the checksum field itself is replaced with zeros.

    The checksum also covers a 96 bit pseudo header conceptually
    prefixed to the TCP header.  This pseudo header contains the Source
    Address, the Destination Address, the Protocol, and TCP length.
    This gives the TCP protection against misrouted segments.  This
    information is carried in the Internet Protocol and is transferred
    across the TCP/Network interface in the arguments or results of
    calls by the TCP on the IP.

                     +--------------------------+
                     |      Source Address      |
                     +--------------------------+
                     |    Destination Address   |
                     +--------------------------+
                     | zero | PTCL | TCP Length |
                     +--------------------------+

      The TCP Length is the TCP header plus the data length in octets
      (this is not an explicitly transmitted quantity, but is computed
      from the total length, and the header length).

À noter également que dans la RFC qui définit l'ICMP, la manière de calculer le checksum est définie individuellement pour chaque message ! A priori, c'est la même chose à chaque fois, mais il faut que même que tu lises une fois la RFC en entier et que tu examines chaque cas un par un pour voir s'il n'y a pas d'exception.

[Shark9]

Re-salut,

je reviens avec un problème, cette fois-ci en TCP, sauf qu'ici, c'est pas un souci de checksum mais de routage de mon packet SYN. Avec wireshark, je vois correctement mon paquet bien formé (similaire à une requête faite avec telnet au port 80) mais une fois envoyé ce SYN TCP, j'ai pas de réponse SYN ACK. Avec snsniff, je capte rien qui sort, donc je suppose que mon paquet ne circule pas sur le réseau d'où le fait d'aucune réponse.

Merci de votre aide.

le code est posté ici :
http://www.developpez.net/forums/d12...c/#post6848066