Lundi 12 Mars 2001

TP de Téléinformatique 2

Organisation des machines

Les 4 stations sont connectées au réseau.

La configuration à partir du fichier etc/hosts à été réalisée comme pour le TP précédent.

Voici les données de cette configuration.

Nom Officiels	Adresses Internet (Classe C)	Adresses Ethernet
Sparc1 (C)	195.0.0.1	00 :b0 :do :5c :5a :fd
Sparc2 (D)	195.0.0.2	00 :b0 :d0 :5c :5a :9b
Sparc3 (B)	195.0.0.3	00 :b0 :d0 :5c :5a :c1
Sparc4 (A)	195.0.0.4	00 :e0 :29 :2b :78 :e9

La machine D constituera la station d’observation des paquets générés sur le réseau avec la commande capt toujours activée.

Protocoles de niveau 3

Le protocole ARP

Génération de paquets ARP :

Pour étudier des paquets de type ARP la commande à effectuer est un ping de A vers B.

Il faut également vider la table de correspondance (@Internet-@Ethernet) pour que des paquets ARP soient générés (pour demander l’ @Ethernet de B) et non seuls les paquets de type ICMP.Pour vider cette table on utilise la commande clear-ARP.

Après le passage des deux paquets de type ARP on arrête capt sur C.

observation de la structures des paquets de type ARP :

Ø ARP request de A vers toutes les stations du réseau pour connaître l’ @ Ethernet de B.

ff ff

ff ff

ff ff

00 e0

29 2b

78 e9

0806

0001

@Ethernet de destination @Ethernet source type ARP

Broadcast

0800

0604

0001

00 e0

29 2b

78 e9

c300

0004

Type IP Sender harware @ Sender protocol @

(195.0.0.4)

ff ff

ff ff

ff ff

c300

0002

Target harware @ Target protocol @ Octets de bourrage

(195.0.0.2)

Octets de bourrage

		Octets de Données

Octet 7 : Ethertype (0806) : Type ARP

Octet 8 :

Octet 9 : Protocol (Type 800) : Type IP

Octet 10 :

Octet 11 :

Ø ARP reply de B vers A pour lui donner son @ Ethernet.

00 e0

29 2b

78 e9

00 b0

do 5c

5a c1

0806

0001

@Ethernet de destination @Ethernet source type ARP

Broadcast

0800

0604

0001

00 b0

do 5c

5a c1

c300

0002

Sender harware @ Sender protocol @

(195.0.0.2)

00 e0

29 2b

78 e9

c300

0004

Target harware @ Target protocol @ Octets de bourrage

(195.0.0.4)

Octets de bourrage

Dans une trame Ethernet le paquet ARP se situe dans la zone Data (entre les bits 368 et 12000).

Le niveau Ethernet connaît la taille des paquet qu’il reçoit grâce à des marqueurs de la couche physique :

Ø Un marqueur de début.

Ø La fin du codage Manchester pour signaler la fin du paquet.

Les éléments qui sont transmis à la couche supérieur sont les données de la trame situées après l’octet Ethertype.

Algorithme du protocole ARP :

Afin de découvrir l’algorithme qui implémente le protocole ARP nous allons réaliser une série de manipulations qui vont viser à compléter les différents champs de l’algorithme.

1)

Manipulations : Dans la table de A on ajoute une entrée pour B.

Dans la table de B on ajoute une entrée pour A.

Ping de A vars B

Résultat : 2 paquets engendrés

- ICMP echo request de A vers B.

- ICMP echo reply de B vers A.

Manipulation : Dans la table de A on supprime l’entré pour B.

Résultat : 4 paquets engendrés

- ARP request de A vers broadcast.

- ARP reply de B vers A.

- ICMP echo request de A vers B.

- ICMP echo reply de B vers A.

Explications : Quand A n’a pas d’entrée pour B dans sa table de correspondance il lui faut la demander au réseau (ARP request).

Le Paquet ARP reply de B à permis à A d’ajouter une entée pour B dans sa table, la communication peut avoir lieu.

2)

Manipulations : Dans la table de A on supprime l’entré pour B ().

Dans les tables de B et C on supprime les entrés pour A.

Ping de A vers B.

Résultats : On note une entré pour A dans les tables de B et C.

3 minutes plus tard l’entrée pour A disparait de la table de C mais pas de celle de B.

Explications : Dans le paquet ARP request destiné à toutes les machines du réseau l’adresse du demandeur est présente (dans l’ARP header) et comme le paquet est lu par tout le réseau toutes ces machines connaissent alors cette adresse.

Au niveau de la disparition des entrées dans les tables des différentes machines on peut dire que leur timer est différent car une est impliquée dans la commande ping (B) et l’autre ‘spectatrice’ de l’opération (C).

3)

Manipulations : Toutes les entrées de toutes les tables sont supprimées (sauf l’entrée spéciales).

Ping de A vers B.

Résultats : 24 paquets semblables sont engendrés et restent sans réponse.

Paquets de type ARP de Sparc 4 vers broadcast :

Who is 195.0.0.3 sparc3

Au niveau de chacune des tables de correspondance une entrée pour A est ajoutée.

Explications : B n’ a pas dans sa table d’entrée pour elle même ce qui veut dire qu’elle ne fait pas le lien entre son @ Internet et son @ Ethernet , donc quand A demande justement cette correspondance ni B ni aucune autre machine du réseau ne peut répondre (pas de paquet ARP reply).

En ce qui concerne l’apparition d’une entrée pour A dans les tables des machines, elle provient du paquet ARP request qui contient ses adresses Internet et Ethernet.

Manipulations : Dans la table de B on ajoute une entrée pour lui même.

Ping de A vers B.

Résultats : Aucuns changements ni par rapport à la capture des messages qui passent sur le réseau ni par rapport aux tables de correspondances.

Explication : Le fait d’ ajouter une entrée pour B dans sa propre table ne suffit pas pour que B « se connaisse » suffisamment pour répondre à A.

Manipulations : Modifier l’entrée pour B dans sa propre table en lui ajoutant l’option publique.

Suppression de l’entrée pour B dans la table de A (cette entrée à été ajouté quand B est devenu publique).

Ping de A vers B.

Résultats : 4 paquets sont engendrés comme dans un communication « normale » D’abord les 2 paquet ARP. Viennent ensuite Les deux paquets ICMP.

Au niveau des tables , toutes les machines ont crée une entrée pour A et A crée une entrée pour B.

Explications : Le fait de rendre publique l’entrée pour B dans sa propre table permet à cette machine de connaître la correspondance entre l’adresse Internet demandé par le paquet ARP request de A et sa propre adresse Ethernet et peut donc lui répondre par un paquet ARP reply.

Remarque : Si on ne supprime pas l’entrée pour B dans la tables de A avant de lancer la commande ping, cette dernière n’a pas besoin du paquet ARP request pour envoyer le paquet ICMP echo request à B et donc aucune tables des machines ne connaîtra l’adresse de A et en particulier B qui ne sait pas à qui renvoyer son paquet ICMP echo reply .

On note alors 32 messages sans réponse de B dont certain sont des ICMP echo request de A vers B et la plupart de B vers broadcast de type ARP echo request (leur ordre dépend de l’expiration des timers de l’ARP et de l’ICMP).

Dans la table de B , A est crée en Unresolved.

4)

Manipulations : Ajout dans la table de C une entrée pour B avec l’option Publique.

Dans la table de A suppression de l’entrée pour B.

Ping de A vers B.

Résultats : On note 5 paquet dont les 4 « habituels » (2 ARP plus 2 ICMP) et un paquet de type ARP reply de C vers A.

Explications : La réponse de B vers A est la réponse normale et celle de C vers A correspond à une réponse à l’ARP de A vers broadcast car C à une entrée publique de B dans sa table et donc connaît la correspondance entre adresse Internet et Ethernet de B.

5)

Manipulations : Ajout d’une entrée dans une table avec l’option publique.

Résultat : On capte 1 paquet de type ARP request de la machine qui ajoute l’entrée :

Explications : Le fait de mettre l’option publique permet d’ajouter dans les tables de toutes les machines une entrée pour cette machine.

C’est ce qui ce passe lors de l’initialisation d’un interface avec la commande ifconfig <interface> up.

6)

Manipulations : Ping vers une machine débranchée du réseau.

Résultat : On capte 24 messages de type ARP request de A vers broadcast.

Après 24 messages le timer de l’ARP arrête l’envoie du message.

Algorithme du protocole ARP :

Tant que vrai faire

Attendre (événement)

Si événement est « question sur adresse Internet ».

IP demande à ARP de consulter la table.

Si possède cette adresse la renvoie à IP .

Sinon renvoie ARP request.

Finsi.

Si événement est expiration du timer associé à une entrée.

ARP enlève l’entrée de la table.

Finsi.

Si événement est réception requête

Si l’adresse concernée est en pub dans la table alors ARP reply

Finsi.

Si événement est réception réponse

ARP ajoute l’entrée dans sa table.

Finsi.

Le protocole ICMP

Calcul du champs Checksum:

Format du paquet Echo Request envoyé :

8

0

00

Type (Echo Request) Code Checksum

11

22

Identifier Sequence Number

Optional Data

On envoie un paquet contenant les différentes valeurs des champs avec la commande :

Send_icmp <station destination> <Nom du Fichier>

Analyse hexadécimale des 2 paquets ICMP qui ont été captés :

( Nous n’observeront que les valeurs des champs de données utiles à la compréhension du calcul du champs Checksum )

Type :

08 00 00 00

Code :

Checksum : f4 fc fc fc

Identifier : 01 01 01 01

Sequence Number : 02 02 02 02

Request Reply

Algorithme de calcul du Checksum : (calcul des deux octets présenté en parallèle)

ff ff

- Type / Code

- Identifier

- Sequence Number

= Checksum

Conclusion :

La vérification de la valeur de ce champ permet de détecter les erreurs d’inversion de bits avec la transformation d’un « 0 » en « 1 » ou inversement.

Par contre si il y plus d’une inversion et qu’elles se compensent, la valeur du champs sera alors juste mais le paquet sera faux. Ce calcul est donc limité à la vérification d’une seule erreur.

Commande ping-s :

L’exécution de cette commande provoque l’envoie périodique de paquets vers une machine du réseau et note les Echo Reply .

L’analyse des paquets transitant par le réseau (autant des ARP Request que de Reply) montre qu’ils sont tous de même type avec respectivement les même sources et destinateurs.

Cette commande permet de tester les capacités du réseau car elle donne en résultat le pourcentage de paquets perdus ainsi que les temps minimums, maximums et moyens d’aller retour d’une requête ARP.

Protocoles de niveau 4

Le protocole UDP

Création des sockets :

Succession des commandes en vue de la configuration des sockets et de l’établissement de la connexion entre 2 machines :

- socklab udp Lancement de Socklab en mode UDP sur les 2 machines.

- socklab udp > sock Création d’une socket sur chacune des machines.

Les sockets sont alors crées :

Machine A : No de port : 34611

Identificateur : 3

Machine B : No de port : 32784

Identificateur : 3

Communication entre les machines :

Commandes de communication :

- socklab udp > sendto <Id Socket> <Nom de la machine> <No du port>

Envoie à partir de A d’un message vers la machine B.

L’identificateur de socket permet de limiter l’envoie du message au port destinataire uniquement et donc identifier de façon unique la connexion (à partir de l’adresse Internet et du numéro du port de la machine destinatrice).

- socklab-udp > recvfrom <Id Socket> <nb d’octets>

Lecture par B d’un message d’un nombre d’octets prédéterminé.

Analyse du paquet capté (Uniquement l’UDP Header) :

Source Port Destination Port

Message Lenght Checksum

Données

Les informations passées au protocole IP par UDP sont les données après le champ Checksum et constituent le codage en ASCII du message envoyé.

L’échange entre l’émetteur et le récepteur du message n’intervient que dans la valeur des champs destinataire et source des différents messages.

Différentes configurations de communication :

1) Demande de réception par B précédant l’envoie du paquet par A:

B attend que A envoie le paquet qui est alors de la même forme que le précédent.

2) Envoie par A de plusieurs paquet avant que B n’en demande la réception :

On reçoit autant de paquets que de messages envoyés.

3) Envoie et demande de réception d’un paquet par A et B simultanément :

On capte 2 paquets qui correspondent aux deux différents messages.

4) Demande de réception de moins d’octets que ceux du message envoyé par A :

B ne lit pas la totalité du message.

(Dans le cas ou B demande à lire plus d’octets il n’y a pas de problèmes).

5) Envoie d’un message vers une machine débranchée :

Le message et quand même envoyé sur le réseau et peut être capté.

6) Envoie de gros paquets vers B:

B ne reçoit que le premier message car la file d’attente de messages n’est que de 10000 octets et donc tous les messages envoyés alors que la file est pleine sont ignorés.

De plus les messages sont divisés car les paquets ne peuvent contenir toute l’information en une seule fois (Ils contiennent l’information not all data contained in this fragment).

7) Envoie d’un paquet par A vers un port inexistant de B:

On capte 2 paquets dont un (de A vers B de type UDP) constitue l’envoie du message et un autre (de B vers A de type ICMP) qui lui, renvoie Destination Unreacheable et Bad Port en remettant le message dans les données.

Communication entre les différentes couches de protocoles :

Au niveau 3 de la machine émettrice c’est le protocole IP qui reçoit les données du protocole de la couche supérieur ici c’est le protocole UDP.

Au niveau de la machine réceptrice c’est le protocole IP qui reçoit le message en entier et le passe à la couche supérieur.

Fonctionnement du protocole UDP :

Réception d’un message :

- Tant qu’il y a des messages dans la file d’attente demander, lire les données envoyées.

- Si la file d’attente est pleine ( 10 000 octets) les message reçu sont ignorés et détruits.

- Si il n’y a pas de message dans la file d’attente, rester en attente de réception.

- Si nombre d’octets à lire est inférieur à la taille du message, ignorer les octets non lus. Au contraire si ce nombre est supérieur, lire la totalité du message jusqu’au dernier octet et ne pas lire d’octets supplémentaires.

- Si il y à réception d’un message destiné à un port inexistant alors la couche ICMP soulève une erreur indiquant l’absence de ce port sur la machine réceptrice.

Emission d’un message :

- Envoyer le message vers un numéro de port et une adresse Internet précise sans se préoccuper de l’état de la machine réceptrice (C’est le travail de la couche IP de dterminer l’adresse physique de cette machine).

- Si le numéro de port est inexistant le message est quand même envoyé (jusqu'à réception de l’erreur soulevé par le protocole ICMP de la machine réceptrice).

Le protocole TCP

Création des sockets :

Succession des commandes en vue de la configuration des sockets et de l’établissement de la connexion entre 2 machines :

- socklab tcp Lancement de Socklab en mode TCP sur les 2 machines.

- socklab tcp > passive Création d’une socket passive sur une machine (B).

- socklab tcp > accept cette socket est destinée à la réception des messages.

La première sockets est alors crée et elle attend la demande de connexion de la part de machine dont la socket sera crée active. 

-socklab tcp > connect <nom de la machine B> <numéro du port précédement crée>

Création d’une socket qui propose la connexion (que B accepte en donnant un numéro d’identificateur à la connexion). A peut alors émettre vers la machine B avec un numéro de port déterminé (La connexion est identifiée précisément).

Etape d’acceptation de la connexion :

La socket passive est d’abord crée, un numéro de port lui est alors attribué.

La socket active peut alors faire une demande de connexion vers ce numéro de port.

Ensuite (ou même avant la demande de connexion) la socket passive accepte cette connexion et un identificateur est alors attribué à la communication .

Observation du contenu des 3 paquets captés durant cette étape d’initialisation de la connexion :

- De A vers B le paquet contient le flag SYN activé.

- De B vers A le paquet contient les flags SYN et ACK activés.

- De A vers B le paquet contient le flag ACK activé.

Le flag SYN correspond donc à une demande de connexion entre sockets et le flag ACK correspond lui à l’acceptation de la proposition (accompagné du flag SYN activé) ou à une indication de bonne réception du message (ACK seul).

Remarque :

- Si l’acceptation est lancée avant la demande de connexion, la socket passive attendra cette demande avant d’envoyer le deuxième paquet.

- Si on ouvre plusieurs connexions de A vers le même port de B, ces dernières sont différenciées grâce aux identificateurs de connexion.

- Si on fait un demande de connexion vers un port inexistant le paquet de demande de connexion contenant le flag SYN est envoyé mais en réponse B envoie un paquet contenant les flags ACK pour signifier la réception de la demande mais le flag RESET est aussi activé pour indiquer que cette connexion est refusée.

Libération d’une connexion :

Commande de fermeture d’un connexion : Socklab-tcp>close

Chaque demande de cloture de connexion engendre 2 paquets :

Le premier va de celui qui ferme la connexion vers l’autre machine et contient (dans la zone TCP) le flag FIN activé (le flag ACK est également activé mais il correspond à un acquittement d’une donnée précédente).

Vient ensuite la réponse qui ne contient elle que le flag ACK activé pour accepter la demande de clôture (elle ferme ensuite la connexion de son coté ce qui génère les mêmes paquets).

Remarque :

- Si B ferme sa socket et que A envoie un message vers cette socket on capte 2 messages dont un de A vers B qui contient les flags SYN et ACK activés et le suivant de B vers A contenant le falg RESET activé.

- Un message broken pipe est alors affiché.

- Si on essai à nouveau d’envoyer un message vers B on ne capte aucuns paquets sur le réseau car le flag RESET à « fait comprendre » à A qu’il n’y avait plus de communication possible avec B.

Commandes Shutdown :

- Une machine en Shutdown-out peut recevoir des messages mais ne peut en envoyer (Broken pipe).

- Une machine en Shutdown-in peut recevoir et envoyer des messages (commande invalide ou inefficace).

- La commande Shutdown-both équivaut à une fermeture de connexion. 

Avantages et inconvénients :

La commande shutdown-out permet l’aspect unilatéral de la connexion avec une machine destinée uniquement à la réception (Cela diminue le nombre de collisions).

La commande close elle evite d’envoyer des messages à un station qui ne pourait pas répondre en bloquant la communication.

Fonctionnement du protocole TCP :

Séquencement et contrôle d’erreur :

Pour étudier ces différents champs on établit une connexion entre les deux machines par sockets TCP et on échange des données entre le machines à l’aide des commandes Write et Read (avec le paramètre #nb pour envoyer des messages d’une taille déterminée).

Notons les valeurs des champs sequence number (SEQ) et ack number (ACK) de l’entête TCP des différents paquets captés sur le réseau :

à A envoie un message de 100 octets à B +100 SEQ : 4242128595 ACK : 502886625

à B envoie l’acquittement de la bonne réception de ce messages SEQ : 502886625 ACK : 4242128695

à B envoie un message de 200 octets à A +200 SEQ : 502886625 ACK : 4242128695

à A envoie l’acquittement de la bonne réception de ce messages SEQ : 4242128695 ACK : 502886825

Algorithme de mise à jour de ces deux champs :

Si A envoie un message vers B

(valeurs des champs du message de A vers B)

SEQ = SEQ du précédent message envoyé + longueur de l’ancien message

ACK = ACK du précédent message envoyé (+ longueur du message reçu )

Si A reçoit un message de B

(valeurs des champs du message de B vers A)

SEQ  = ACK du message reçu

ACK  = SEQ du message reçu + longueur de ce message

La mise à jour de ces zones permet au protocole TCP de vérifier si les paquets reçu ne sont pas des doublons ou si il manque des paquets dans la chronologie (si un paquet envoyé après un autre est reçu avant lui)

Remarque :

Si A envoie un message vers la station B débranchée du réseau on observe les paquets suivants :

- 5 paquet de A vers B avec les flags PUSH et ACK pour signifier l’envoie de message.

- Une vingtaine de paquets de tye ARP request de A vers broadcast pour demander l’adresse physique de B

Echange de données urgentes :

Pour étudier ce type de communication on établit une connexion entre les deux machines par sockets TCP et on échange des données entre le machines à l’aide des commandes Write et Read (avec le paramètre #nb pour envoyer des messages d’une taille déterminée).

En plus de ces commandes on échange des données urgentes entre les deux machines à l’aides des commandes :

Socklab-tcp>usend<nb d’octets> envoi de données urgentes (1 seul octet )

Socklab-tcp>urecv reception de ces données

Observation des paquets :

- Dans l’envoie d’un paquet de données urgentes le flag URGENT de l’entête TCP est activé (ainsi que le flag ACK).

- Envoie de plusieurs messages non urgent puis d’un paquet urgent et demande de lacture de ce paquet avant d’avoir lu les précédents : on lit l’octet de données urgentes. Un paquet de données urgentes est bienlu en priorité par rapport à des paquets de données « normales » (grâce à la commande de réception de données urgentes).

Conclusion :

Les machines possèdent 2 files d’attentes distinctes : une pour les données sans priorité et une pour les données urgentes.

On peut donc dire que ce type de communication est utile si la file de données de la machine réceptrice est pleine et que l’on veut quand même lui faire passer une information car on peut alors se servir de la file de données urgentes.

Contrôle de flux :

On crée une connexion TCP sur les deux machines (A propose la connexion et B l’accepte).

A partir de A on envoie un message de 40 000 octets et on capte les paquets voyageant sur le réseau.

On capte ainsi 64 paquets :

- Les 31 premiers paquets transporte une partie des données (leur champs window est de 8760)puis la file d’attente de B est pleine (leur champs window est de 0).

- On vide cette file en lisant le message par morceaux de 5000 octets ( ce qui est possible car le protocole TCP est de type « byte stream » ce qui veut dire que comme l’unité d’information est l’octet le message peut être lu avec n’importe quel découpage).

- On observe à nouveau des paquets de données.

- On note également que pendant la période ou la file d’attente de B est pleine on observe des paquets ARP echo request tous les 4 paquets dont le champs window est de 0.

Fragmentation des paquets IP

1) On crée une connexion UDP sur les deux machines :

A partir d’une machine, on envoie un paquet de 4600 octets vers l’autre.

Observation de l’activité du réseau :

On capte 4 paquets sur le réseau

Voici les différentes valeurs des champs des paquets contenant le message susceptibles de permettre la compréhension du phénomène de fragmentation par le protocole IP.

	TOTAL LENGH	FRAGMENT OFFSET	MORE FRAGMENT
Paquet 1	1500	0	1
Paquet 2	1500	1480	1
Paquet 3	1500	2960	1
Paquet 4	188	4440	0

Le champ offset correspond à la taille du message qui à déjà été envoyée.

La différence de 20 octets entre la taille du paquet et l’offset correspond à la taille de l’entête UDP qui n’est pas comptée quand on considère la taille du message déjà transmise car on traite des information de ce protocole qui donc on ne lit que les données (ce qui comprend également l’entête IP) et non l’entête UDP elle même (notons que la dernière entête fait 28 octets).

Le champ MF indique si le paquet constitue ou non le dernier fragment du message donc si il a encore des paquets à venir.

2) On crée une connexion TCP sur les deux machines :

A partir d’une machine, on envoie un paquet de 4600 octets vers l’autre.

Observation de l’activité du réseau :

On capte 4 paquets sur le réseau de A vers B et 2 acquittements de B vers A.

Voici les différentes valeurs des champs des paquets contenant le message susceptibles de permettre la compréhension du phénomène de fragmentation par le protocole IP.

	TOTAL LENGH	FRAGMENT OFFSET	MORE FRAGMENT
Paquet 1	1500	0	0
Paquet 2	1500	0	0
Paquet 3	1500	0	0
Paquet 4	220	0	0

Dans les 1500 octets du paquet il y en a 20 pour l’entête IP et 20 pour l’entête TCP.

Donc la taille du message fait bien (1500-40)*3 +220 = 4600

3) Conclusions :

On déduite de ces observations que dans la cas du protocole UDP pour qui l’unité d’information est les message c’est le protocole IP qui s’occupe de la fragmentation en indiquant la quantité du message déjà fragmenté et s’il faut encore d’autre fragments pour retrouver le message envoyé.

Par contre en ce qui concerne le protocole TCP on observe que la fragmentation est automatique et que le protocole IP n’intervient pas car pour TCP l’unité d’information est l’octet et donc un message trop long pour un seul paquet est divisé et les paquets sont envoyé jusqu'à ce que la totalité du message ait été lu par la machine réceptrice.

Synthèse

Commande Talk

On observe une succession de paquets de type UPD TALK C de A vers B et TALK R de B vers A.

On note que chaque caractère entraîne l’envoie de 2 paquets en sens contraire ( le premier contient le caractère ainsi que la flag PUSH activé et le second constitue l’acquittement de ce message).

L’initialisation de la connexion se fait par deux paquet de type TCP dont l’un allant de A vers B contenant le flag SYN activé et l’autre allant dans l’autre sens contenant lui les flag ACK et SYN activés (ces deux paquets se répètent si aucuns caractère n’est tapé).

La fermeture de cette connexion est faite par deux groupes de deux paquets semblables mais ce n’est plus le flag SYN mais FIN qui est activé dans les 4 paquets ( avec ou sans le flag ACK).