PAGE DE MANUEL TCPDUMP(1)

Section : Commandes utilisateur (1)

Mise à jour : 21 octobre 2023
Index Retour au contenu principal
Cette page de manuel documente tcpdump version 5.0.0-PRE-GIT (voir
aussi : 4.99.4 , 4.99.2 , 4.99.1 , 4.99.0 , 4.9.3 , 4.9.2 , 4.9.1 , 4.9.0 , 4.8 .1 , 4.7.4 , 4.6.
2 , 4.5.1 , 4.4.0 ).

Votre système peut avoir une version différente installée, éventuellement avec
quelques modifications locales. Pour obtenir les meilleurs résultats, assurez-
vous que cette version de cette page de manuel répond à vos besoins. Si
nécessaire, essayez de rechercher une version différente sur ce site Web ou
dans les pages de manuel disponibles dans votre installation.
NOM
tcpdump - vider le trafic sur un réseau
SYNOPSIS
tcpdump [ -AbdDefhHIJKlLnNOpqStuUvxX# ] [ -B taille_tampon ]
[ -c nombre ] [ --compte ] [ -C taille_fichier ]
[ -E spi@ipaddr algo:secret,... ]
[ -F fichier ] [ -G rotation_secondes ] [ -i interface ]
[ --immediate-mode ] [ -j tstamp_type ] [ -m module ]
[ -M secret ] [ --number ] [ --print ]
[ --print-sampling nth ] [ -Q in| out|inout ] [ -r fichier ]
[ -s snaplen ] [ -T type ] [ --version ] [ -V fichier ]
[ -w fichier ] [ -W filecount ] [ -y datalinktype ]
[ -z postrotate-commande ] [ -Z utilisateur ]
[ --time-stamp-precision= tstamp_precision ]
[ --micro ] [ --nano ]
[ expression ]
DESCRIPTION
Tcpdump affiche une description du contenu des paquets sur une interface
réseau qui correspond à l' expression booléenne (voir pcap-filter (7) pour la
syntaxe de l'expression ) ; la description est précédée d'un horodatage,
imprimé par défaut en heures, minutes, secondes et fractions de seconde
depuis minuit. Il peut également être exécuté avec l' indicateur -w , ce qui
l'amène à enregistrer les données du paquet dans un fichier pour une analyse
ultérieure, et/ou avec l' indicateur -r , qui l'amène à lire à partir d'un fichier de
paquets enregistré plutôt que de lire les paquets. à partir d’une interface
réseau. Il peut également être exécuté avec l' indicateur -V , ce qui lui permet
de lire une liste de fichiers de paquets enregistrés. Dans tous les cas, seuls
les paquets correspondant à l'expression seront traités par tcpdump .

Tcpdump , s'il n'est pas exécuté avec l' option -c , continuera à capturer les
paquets jusqu'à ce qu'il soit interrompu par un signal SIGINT (généré, par
exemple, en tapant votre caractère d'interruption, généralement contrôle-C)
ou un signal SIGTERM (généralement généré avec le kill (1) commande); s'il
est exécuté avec l' indicateur -c , il capturera les paquets jusqu'à ce qu'il soit
interrompu par un signal SIGINT ou SIGTERM ou que le nombre spécifié de
paquets ait été traité.

Lorsque tcpdump aura fini de capturer les paquets, il signalera le nombre de :

paquets « capturés » (c'est le nombre de paquets que tcpdump a reçus

et traités) ;

paquets ``reçus par filtre'' (la signification de ceci dépend du système

d'exploitation sur lequel vous exécutez tcpdump , et éventuellement de
la façon dont le système d'exploitation a été configuré - si un filtre a été
spécifié sur la ligne de commande, sur certains systèmes d'exploitation,
cela compte paquets, qu'ils correspondent ou non à l'expression de filtre
et, même s'ils correspondent à l'expression de filtre, que tcpdump les ait
déjà lus et traités ou non, sur d'autres systèmes d'exploitation, il ne
compte que les paquets qui correspondent à l'expression de filtre,
indépendamment du fait que tcpdump les a déjà lus et traités.
si tcpdump les a déjà lus et traités, et sur d'autres systèmes
d'exploitation, il ne compte que les paquets correspondant à
l'expression de filtre et traités par tcpdump );

paquets « abandonnés par le noyau » (c'est le nombre de paquets qui

ont été abandonnés, en raison d'un manque d'espace tampon, par le
mécanisme de capture de paquets du système d'exploitation sur lequel
tcpdump est exécuté, si le système d'exploitation rapporte cette
information aux applications ; sinon, il sera signalé comme 0).

Sur les plates-formes prenant en charge le signal SIGINFO, telles que la

plupart des BSD (y compris macOS) et Digital/Tru64 UNIX, il signalera ces
décomptes lorsqu'il recevra un signal SIGINFO (généré, par exemple, en
tapant votre caractère « statut », généralement control-T, bien que sur
certaines plates-formes, comme macOS, le caractère « status » n'est pas
défini par défaut, vous devez donc le définir avec stty (1) pour pouvoir
l'utiliser) et continuerez à capturer les paquets. Sur les plates-formes qui ne
prennent pas en charge le signal SIGINFO, la même chose peut être obtenue
en utilisant le signal SIGUSR1.

L'utilisation du signal SIGUSR2 avec l' indicateur -w videra de force le tampon

du paquet dans le fichier de sortie.

La lecture de paquets à partir d'une interface réseau peut nécessiter que vous
disposiez de privilèges spéciaux ; consultez la page de manuel pcap (3PCAP)
pour plus de détails. La lecture d'un fichier de paquets enregistré ne nécessite
pas de privilèges spéciaux.

OPTIONS
-UN
Imprimez chaque paquet (moins son en-tête de niveau lien) en
ASCII. Pratique pour capturer des pages Web.

-b
Imprimez le numéro AS dans les paquets BGP en notation ASDOT
plutôt qu'en notation ASPLAIN.

-B taille_tampon
--buffer-size= taille_tampon
Définissez la taille du tampon de capture du système d’exploitation
sur buffer_size , en unités de KiB (1 024 octets).

-c compte
Quittez après avoir reçu le nombre de paquets.

--compter
Imprimez uniquement sur la sortie standard le nombre de paquets lors
de la lecture du ou des fichiers de capture au lieu d'analyser/imprimer
les paquets. Si un filtre est spécifié sur la ligne de
commande, tcpdump compte uniquement les paquets correspondant à
l'expression du filtre.

-C taille_fichier
Avant d'écrire un paquet brut dans un fichier de sauvegarde, vérifiez si
le fichier est actuellement plus grand que file_size et, si c'est le cas,
fermez le fichier de sauvegarde actuel et ouvrez-en un nouveau. Les
 fichiers de sauvegarde après le premier fichier de sauvegarde porteront
le nom spécifié avec l' indicateur -w , suivi d'un numéro, commençant à
1 et continuant vers le haut. L'unité par défaut de file_size est le million
d'octets (1 000 000 octets et non 1 048 576 octets).

En ajoutant un suffixe k/K, m/M ou g/G à la valeur, l'unité peut être

modifiée respectivement en 1 024 (KiB), 1 048 576 (MiB) ou
1 073 741 824 (GiB).

-d
Videz le code de correspondance de paquets compilé sous une forme
lisible par l'homme vers la sortie standard et arrêtez-vous.

Veuillez noter que bien que la compilation de code soit toujours

spécifique au DLT, il est généralement impossible (et inutile) de
spécifier quel DLT utiliser pour le vidage car tcpdump utilise soit le DLT
du fichier pcap d'entrée spécifié avec -r , soit le DLT par défaut de
l'interface réseau spécifiée avec -i , ou le DLT particulier de l'interface
réseau spécifié avec -y et -i respectivement. Dans ces cas, le dump
affiche exactement le même code qui filtrerait le fichier d'entrée ou
l'interface réseau sans -d .

Cependant, lorsque ni -r ni -i ne sont spécifiés, spécifier -

d empêche tcpdump de deviner une interface réseau appropriée (voir -
i ). Dans ce cas, le DLT est par défaut EN10MB et peut être défini
manuellement sur une autre valeur valide avec -y .

-jj
Videz le code de correspondance de paquets en tant que fragment de
programme C.

-ddd
Vider le code de correspondance de paquets sous forme de nombres
décimaux (précédés d'un décompte).

-D
--list-interfaces
Imprimez la liste des interfaces réseau disponibles sur le système et sur
lesquelles tcpdump peut capturer des paquets. Pour chaque interface
réseau, un numéro et un nom d'interface, éventuellement suivis d'une
description textuelle de l'interface, sont imprimés. Le nom de l'interface
ou le numéro peut être fourni à l' indicateur -i pour spécifier une
interface sur laquelle capturer.
 Cela peut être utile sur les systèmes qui n'ont pas de commande pour
les lister (par exemple, les systèmes Windows ou les systèmes UNIX
dépourvus de ifconfig -a ) ; le numéro peut être utile sur les systèmes
Windows 2000 et versions ultérieures, où le nom de l'interface est une
chaîne quelque peu complexe.

L' indicateur -D ne sera pas pris en charge si tcpdump a été construit

avec une ancienne version de libpcap dépourvue de
la fonction pcap_findalldevs (3PCAP).

-e
Imprimez l'en-tête au niveau du lien sur chaque ligne de vidage. Cela
peut être utilisé, par exemple, pour imprimer les adresses de couche
MAC pour des protocoles tels qu'Ethernet et IEEE 802.11.

-E
Utilisez spi@ipaddr algo:secret pour déchiffrer les paquets ESP IPsec
adressés à l'adresse et contenant la valeur de l'index des paramètres
de sécurité spi . Cette combinaison peut être répétée avec une
séparation par virgule ou par nouvelle ligne.

Notez que la définition du secret pour les paquets ESP IPv4 est
actuellement prise en charge.

Les algorithmes peuvent être des-cbc , 3des-cbc , Blowfish-cbc , rc3-

cbc , cast128-cbc ou none . La valeur par défaut est des-cbc . La
possibilité de déchiffrer les paquets n'est présente que si tcpdump a été
compilé avec la cryptographie activée.

secret est le texte ASCII de la clé secrète ESP. Si précédé de 0x, alors
une valeur hexadécimale sera lue.

L’option suppose la RFC 2406 ESP, et non la RFC 1827 ESP. L'option
est uniquement destinée à des fins de débogage, et l'utilisation de cette
option avec une véritable clé « secrète » est déconseillée. En
présentant la clé secrète IPsec sur la ligne de commande, vous la
rendez visible aux autres, via ps (1) et à d'autres occasions.

En plus de la syntaxe ci-dessus, le nom du fichier de syntaxe peut être

utilisé pour que tcpdump lise le fichier fourni. Le fichier est ouvert à la
réception du premier paquet ESP, donc toutes les autorisations
spéciales que tcpdump a pu avoir accordées devraient déjà avoir été
abandonnées. .
-F
Imprimer les adresses IPv4 « étrangères » numériquement plutôt que
symboliquement (cette option est destinée à contourner de graves
lésions cérébrales dans le serveur NIS de Sun --- généralement, elle se
bloque pour toujours en traduisant des numéros Internet non locaux).

Le test des adresses IPv4 « étrangères » est effectué en utilisant

l'adresse IPv4 et le masque de réseau de l'interface sur cette
capture. Si cette adresse ou ce masque de réseau ne sont pas
disponibles, soit parce que l'interface sur cette capture en cours n'a pas
d'adresse ni de masque de réseau, soit parce qu'il s'agit de la pseudo-
interface "n'importe quelle", disponible sous Linux et dans les versions
récentes de macOS et Solaris, et qui peut capturer sur plusieurs
interfaces, cette option ne fonctionnera pas correctement.

Fichier -F
Utilisez le fichier comme entrée pour l’expression de filtre. Une
expression supplémentaire donnée sur la ligne de commande est
ignorée.

-G rotation_secondes
Si spécifié, fait pivoter le fichier de vidage spécifié avec l' option -
w toutes les rotate_seconds secondes. Les fichiers de sauvegarde
auront le nom spécifié par -w qui doit inclure un format d'heure tel que
défini par strftime (3). Si aucun format d'heure n'est spécifié, chaque
nouveau fichier écrasera le précédent. Chaque fois qu'un nom de fichier
généré n'est pas unique, tcpdump écrasera les données
préexistantes ; il n’est donc pas conseillé de fournir une spécification
temporelle plus grossière que la période de capture.

S'ils sont utilisés conjointement avec l' option -C , les noms de fichiers
prendront la forme de ` file <count>'.

-h
--aide
Imprimez les chaînes de version tcpdump et libpcap, imprimez un
message d'utilisation et quittez.

--version
Imprimez les chaînes de version tcpdump et libpcap et quittez.

-H
Tentative de détection des brouillons d'en-têtes de maillage 802.11.
-je interface
--interface= interface
Écoutez, signalez la liste des types de couche de liaison, signalez la
liste des types d'horodatage ou signalez les résultats de la compilation
d'une expression de filtre sur l' interface . S'il n'est pas spécifié et si l'
option -d n'est pas donnée, tcpdump recherche dans la liste des
interfaces système l'interface configurée avec le numéro le plus bas (à
l'exclusion du bouclage), qui peut s'avérer être, par exemple, « eth0 ».

Sur les systèmes Linux dotés de noyaux 2.2 ou ultérieurs et sur les
versions récentes de macOS et Solaris, un argument d'interface de
« any » peut être utilisé pour capturer les paquets de toutes les
interfaces. Notez que les captures sur la pseudo-interface « any » ne se
feront pas en mode promiscuité.

Si l' indicateur -D est pris en charge, un numéro d'interface tel

qu'imprimé par cet indicateur peut être utilisé comme
argument d'interface , si aucune interface du système n'a ce numéro
comme nom.

-JE
--mode-moniteur
Mettez l'interface en "mode moniteur" ; ceci n'est pris en charge que sur
les interfaces Wi-Fi IEEE 802.11 et uniquement sur certains systèmes
d'exploitation.

Notez qu'en mode moniteur, l'adaptateur peut se dissocier du réseau

auquel il est associé, de sorte que vous ne pourrez pas utiliser de
réseaux sans fil avec cet adaptateur. Cela pourrait empêcher l'accès
aux fichiers sur un serveur réseau ou la résolution des noms d'hôte ou
des adresses réseau si vous capturez en mode moniteur et n'êtes pas
connecté à un autre réseau avec un autre adaptateur.

Cet indicateur affectera la sortie de l' indicateur -L . Si -I n'est pas

spécifié, seuls les types de couche de liaison disponibles lorsqu'ils ne
sont pas en mode moniteur seront affichés ; si -I est spécifié, seuls les
types de couche de liaison disponibles en mode moniteur seront
affichés.

--mode immédiat
Capturez en "mode immédiat". Dans ce mode, les paquets sont
transmis à tcpdump dès leur arrivée, plutôt que d'être mis en mémoire
tampon pour des raisons d'efficacité. C'est la valeur par défaut lors de
 l'impression de paquets plutôt que de la sauvegarde des paquets dans
un « fichier de sauvegarde » si les paquets sont imprimés sur un
terminal plutôt que sur un fichier ou un canal.

-j type_tstamp
--time-stamp-type= tstamp_type
Définissez le type d'horodatage de la capture sur tstamp_type . Les
noms à utiliser pour les types d'horodatage sont donnés dans pcap-
tstamp (7) ; tous les types répertoriés ne seront pas nécessairement
valides pour une interface donnée.

-J
--list-time-stamp-types
Répertoriez les types d’horodatage pris en charge pour l’interface et
quittez. Si le type d’horodatage ne peut pas être défini pour l’interface,
aucun type d’horodatage n’est répertorié.

--time-stamp-precision= tstamp_precision
Lors de la capture, définissez la précision de l'horodatage de la capture
sur tstamp_precision . Notez que la disponibilité d'horodatages de haute
précision (nanosecondes) et leur précision réelle dépendent de la plate-
forme et du matériel. Notez également que lors de l'écriture de captures
réalisées avec une précision de la nanoseconde dans un fichier de
sauvegarde, les horodatages sont écrits avec une résolution de la
nanoseconde et le fichier est écrit avec un nombre magique différent,
pour indiquer que les horodatages sont en secondes et en
nanosecondes ; tous les programmes qui lisent les fichiers de
sauvegarde pcap ne pourront pas lire ces captures.

Lors de la lecture d'un fichier de sauvegarde, convertissez les

horodatages avec la précision spécifiée par timestamp_precision et
affichez-les avec cette résolution. Si la précision spécifiée est inférieure
à la précision des horodatages dans le fichier, la conversion perdra en
précision.

Les valeurs prises en charge pour timestamp_precision sont micro pour

une résolution en microsecondes et nano pour une résolution en
nanosecondes. La résolution par défaut est en microsecondes.

--micro
--nano
Raccourcis pour --time-stamp-precision=micro ou --time-stamp-
precision=nano , ajustant la précision de l'horodatage en
 conséquence. Lors de la lecture de paquets à partir d'un fichier de
sauvegarde, l'utilisation de --micro tronque les horodatages si le fichier
de sauvegarde a été créé avec une précision de la nanoseconde. En
revanche, un fichier de sauvegarde créé avec une précision de la
microseconde aura des zéros à droite ajoutés à l'horodatage lorsque --
nano est utilisé.

-K
--ne pas vérifier les sommes de contrôle
N'essayez pas de vérifier les sommes de contrôle IP, TCP ou
UDP. Ceci est utile pour les interfaces qui effectuent tout ou partie de
ces calculs de somme de contrôle dans le matériel ; sinon, toutes les
sommes de contrôle TCP sortantes seront signalées comme
incorrectes.

-l
Rendre la ligne stdout mise en mémoire tampon. Utile si vous souhaitez
voir les données lors de leur capture. Par exemple,

tcpdump -l | tee-shirt
ou

tcpdump -l > date et queue -f date

Notez que sous Windows, ``line buffered'' signifie ``unbuffered'', de
sorte que WinDump écrira chaque caractère individuellement si -l est
spécifié.

-U est similaire à -l dans son comportement, mais cela fera en sorte que
la sortie soit « tamponnée par paquets », de sorte que la sortie soit
écrite sur la sortie standard à la fin de chaque paquet plutôt qu'à la fin
de chaque ligne ; ceci est mis en mémoire tampon sur toutes les plates-
formes, y compris Windows.

-L
--list-data-link-types
Répertoriez les types de liaison de données connus pour l'interface,
dans le mode spécifié, et quittez. La liste des types de liaison de
données connus peut dépendre du mode spécifié ; par exemple, sur
certaines plates-formes, une interface Wi-Fi peut prendre en charge un
ensemble de types de liaison de données lorsqu'elle n'est pas en mode
moniteur (par exemple, elle peut prendre en charge uniquement de faux
en-têtes Ethernet, ou peut prendre en charge les en-têtes 802.11 mais
 pas les en-têtes 802.11 avec informations radio) ) et un autre ensemble
de types de liaison de données en mode surveillance (par exemple, il
peut prendre en charge les en-têtes 802.11 ou les en-têtes 802.11 avec
informations radio, uniquement en mode surveillance).

-mmodule _
Chargez les définitions du module SMI MIB à partir du module de
fichiers . Cette option peut être utilisée plusieurs fois pour charger
plusieurs modules MIB dans tcpdump .

-M secret
Utilisez secret comme secret partagé pour valider les résumés trouvés
dans les segments TCP avec l'option TCP-MD5 (RFC 2385), si
présente.

-n
Ne convertissez pas les adresses (c'est-à-dire les adresses d'hôte, les
numéros de port, etc.) en noms.

-N
N'imprimez pas la qualification du nom de domaine des noms
d'hôte. Par exemple, si vous donnez cet indicateur, tcpdump affichera «
nic » au lieu de « nic.ddn.mil ».

-#
--nombre
Imprimez un numéro de paquet facultatif au début de la ligne.

-O
--pas d'optimisation
N'exécutez pas l'optimiseur de code de correspondance de
paquets. Ceci n'est utile que si vous soupçonnez un bug dans
l'optimiseur.

-p
--pas de promiscuité
Ne mettez pas l'interface en mode promiscuité. Notez que l'interface
peut être en mode promiscuité pour une autre raison ; par conséquent,
« -p » ne peut pas être utilisé comme abréviation de « hôte Ethernet
{local-hw-addr} ou diffusion Ethernet ».

--imprimer
 Imprime la sortie des paquets analysés, même si les paquets bruts sont
enregistrés dans un fichier avec l' indicateur -w .

--print-sampling= nième
Imprimez un paquet sur nième . Cette option active l' indicateur --print .

Les paquets non imprimés ne sont pas analysés, ce qui réduit le temps
de traitement. Définir nth sur 100 par exemple (en comptant à partir de
1) analysera et imprimera le 100ème paquet, le 200ème paquet, le
300ème paquet, et ainsi de suite.

Cette option active également l' indicateur -S , car les numéros de

séquence TCP relatifs ne sont pas suivis pour les paquets non
imprimés.

Direction -Q
--direction= direction
Choisissez la direction d’envoi/réception pour laquelle les paquets
doivent être capturés. Les valeurs possibles sont « in », « out » et «
inout ». Non disponible sur toutes les plateformes.

-q
Sortie rapide (silencieuse ?). Imprimez moins d'informations de
protocole afin que les lignes de sortie soient plus courtes.

-r fichier
Lire les paquets à partir d' un fichier (qui a été créé avec l' option -w ou
par d'autres outils qui écrivent des fichiers pcap ou pcapng). L'entrée
standard est utilisée si le fichier est ``-''.

-S
--numéros de séquence absolus-tcp
Imprimez les numéros de séquence TCP absolus plutôt que relatifs.

-s snaplen
--snapshot-length= snaplen
Snaflen octets de données de chaque paquet plutôt que la valeur par
défaut de 262 144 octets . Les paquets tronqués en raison d'un
instantané limité sont indiqués dans la sortie par ``[| proto ]'',
où proto est le nom du niveau de protocole auquel la troncature a eu
lieu.
 Notez que la prise d'instantanés plus grands augmente à la fois le
temps nécessaire au traitement des paquets et, effectivement, diminue
la quantité de mise en mémoire tampon des paquets. Cela peut
entraîner la perte de paquets. Notez également que la prise
d'instantanés plus petits supprimera les données des protocoles situés
au-dessus de la couche de transport, ce qui perdra des informations qui
peuvent être importantes. Les requêtes et réponses NFS et AFS, par
exemple, sont très volumineuses et une grande partie des détails ne
seront pas disponibles si une longueur d'instantané trop courte est
sélectionnée.

Si vous devez réduire la taille de l'instantané en dessous de la taille par

défaut, vous devez limiter snaplen au plus petit nombre qui capturera
les informations de protocole qui vous intéressent. Définir snaplen sur 0
le définit sur la valeur par défaut de 262144, pour une compatibilité
ascendante avec les anciens modèles récents. versions de tcpdump .

-Type T
Force les paquets sélectionnés par « expression » à être interprétés
selon le type spécifié . Les types actuellement connus sont aodv (Ad-
hoc On-demand Distance Vector protocol), carp (Common Address
Redundancy Protocol), cnfp (protocole Cisco
NetFlow), domain (Domain Name System), lmp (Link Management
Protocol), pgm (Pragmatic General Multicast), pgm_zmtp1 (ZMTP/1.0
dans PGM/EPGM), ptp (Precision Time
Protocol), quic (QUIC), radius (RADIUS), resp (REdis Serialization
Protocol), rpc (Remote Procedure Call), rtcp (Real-Time Protocole de
contrôle des applications), rtp (protocole d'applications en temps
réel), snmp (Simple Network Management
Protocol), someip (SOME/IP), tftp (Trivial File Transfer
Protocol), vat (Visual Audio Tool), vxlan (Virtual eXtensible Local Area
Network), wb (Tableau blanc distribué) et zmtp1 (ZeroMQ Message
Transport Protocol 1.0).

Notez que le type pgm ci-dessus affecte uniquement l'interprétation

UDP, le PGM natif est toujours reconnu comme le protocole IP 113,
quel que soit le cas. Le PGM encapsulé en UDP est souvent appelé «
EPGM » ou « PGM/UDP ».

Notez que le type pgm_zmtp1 ci-dessus affecte l'interprétation à la fois

du PGM natif et de l'UDP. Lors du décodage PGM natif, les données
d'application d'un paquet ODATA/RDATA seraient décodées sous
 forme de datagramme ZeroMQ avec des trames ZMTP/1.0. En outre,
pendant le décodage UDP, tout paquet UDP serait traité comme un
paquet PGM encapsulé.

-t
N'imprimez pas d'horodatage sur chaque ligne de vidage.

-tt
Imprimez l'horodatage, en secondes depuis le 1er janvier 1970,
00:00:00, UTC, et en fractions de seconde depuis cette heure, sur
chaque ligne de vidage.

-ttt
Imprimez un delta (résolution en microsecondes ou nanosecondes
selon l' option --time-stamp-precision ) entre la ligne actuelle et la
ligne précédente sur chaque ligne de vidage. La résolution par défaut
est en microsecondes.

-tttt
Imprimez un horodatage sous forme d'heures, de minutes, de secondes
et de fractions de seconde depuis minuit, précédé de la date, sur
chaque ligne de vidage.

-ttttt
Imprimez un delta (résolution en microsecondes ou nanosecondes
selon l' option --time-stamp-precision ) entre la ligne actuelle et la
première ligne sur chaque ligne de vidage. La résolution par défaut est
en microsecondes.

-u
Imprimez les handles NFS non décodés.

-U
--paquet-bufferisé
Si l' option -w n'est pas spécifiée, ou si elle est spécifiée mais que l'
option --print est également spécifiée, faites en sorte que le paquet
imprimé soit « packet-buffered » ; c'est-à-dire que lorsque la description
du contenu de chaque paquet est imprimée, elle sera écrite sur la sortie
standard, plutôt que, lorsqu'il n'est pas écrit sur un terminal, d'être écrite
uniquement lorsque le tampon de sortie se remplit.

Si l' option -w est spécifiée, rend le paquet brut enregistré en sortie

« packet-buffered » ; c'est-à-dire que lorsque chaque paquet est
 enregistré, il sera écrit dans le fichier de sortie, plutôt que d'être écrit
uniquement lorsque le tampon de sortie se remplira.

L' indicateur -U ne sera pas pris en charge si tcpdump a été construit

avec une ancienne version de libpcap dépourvue de la
fonction pcap_dump_flush (3PCAP).

-v
Lors de l’analyse et de l’impression, produisez (un peu plus) une sortie
détaillée. Par exemple, la durée de vie, l'identification, la longueur totale
et les options d'un paquet IP sont imprimées. Permet également des
contrôles supplémentaires d’intégrité des paquets, tels que la
vérification de la somme de contrôle de l’en-tête IP et ICMP.

Lorsque vous écrivez dans un fichier avec l' option -w et que vous ne
lisez pas en même temps un fichier avec l' option -r , signalez à stderr,
une fois par seconde, le nombre de paquets capturés. Sous Solaris,
FreeBSD et éventuellement d'autres systèmes d'exploitation, cette mise
à jour périodique peut actuellement entraîner la perte de paquets
capturés lors de leur passage du noyau vers tcpdump.

-vv
Sortie encore plus verbeuse. Par exemple, des champs
supplémentaires sont imprimés à partir des paquets de réponse NFS et
les paquets SMB sont entièrement décodés.

-vvv
Sortie encore plus verbeuse. Par exemple, les options
telnet SB … SE sont imprimées dans leur intégralité. Avec -X, les
options Telnet sont également imprimées en hexadécimal.

Fichier -V
Lisez une liste de noms de fichiers à partir du fichier . L'entrée standard
est utilisée si le fichier est ``-''.

-w fichier
Écrivez les paquets bruts dans un fichier plutôt que de les analyser et
de les imprimer. Ils peuvent ensuite être imprimés avec l'option -r. La
sortie standard est utilisée si le fichier est ``-''.

Cette sortie sera mise en mémoire tampon si elle est écrite dans un
fichier ou un canal, de sorte qu'un programme lisant à partir du fichier
ou du canal peut ne pas voir les paquets pendant une durée arbitraire
 après leur réception. Utilisez l' indicateur -U pour que les paquets soient
écrits dès leur réception.

Le type MIME application/vnd.tcpdump.pcap a été enregistré auprès de

l'IANA pour les fichiers pcap . L'extension de nom de
fichier .pcap semble être la plus couramment utilisée
avec .cap et .dmp . Tcpdump lui-même ne vérifie pas l'extension lors de
la lecture des fichiers de capture et n'ajoute pas d'extension lors de leur
écriture (il utilise à la place des nombres magiques dans l'en-tête du
fichier). Cependant, de nombreux systèmes d'exploitation et
applications utiliseront l'extension si elle est présente et il est
recommandé d'en ajouter une (par exemple .pcap).

Voir pcap-savefile (5) pour une description du format de fichier.

-W nombre de fichiers
Utilisé conjointement avec l' option -C , cela limitera le nombre de
fichiers créés au nombre spécifié et commencera à écraser les fichiers
depuis le début, créant ainsi un tampon « rotatif ». De plus, il nommera
les fichiers avec suffisamment de 0 en tête pour prendre en charge le
nombre maximum de fichiers, leur permettant ainsi d'être triés
correctement.

Utilisé conjointement avec l' option -G , cela limitera le nombre de

fichiers de vidage en rotation créés, sortant avec l'état 0 lorsque la limite
est atteinte.

Si elle est utilisée conjointement avec -C et -G, l' option -W sera

actuellement ignorée et n'affectera que le nom du fichier.

-X
Lors de l'analyse et de l'impression, en plus d'imprimer les en-têtes de
chaque paquet, imprimez les données de chaque paquet (moins son
en-tête de niveau lien) en hexadécimal. Le plus petit du paquet entier
ou des octets instantanés sera imprimé. Notez qu'il s'agit de l'intégralité
du paquet de couche liaison, donc pour les couches de liaison qui
remplissent (par exemple Ethernet), les octets de remplissage seront
également imprimés lorsque le paquet de couche supérieure est plus
court que le remplissage requis. Dans l'implémentation actuelle, cet
indicateur peut avoir le même effet que -xx si le paquet est tronqué.

-xx
 Lors de l'analyse et de l'impression, en plus d'imprimer les en-têtes de
chaque paquet, imprimez les données de chaque paquet, y compris son
en-tête au niveau du lien, en hexadécimal.

-X
Lors de l'analyse et de l'impression, en plus d'imprimer les en-têtes de
chaque paquet, imprimez les données de chaque paquet (moins son
en-tête de niveau lien) en hexadécimal et ASCII. C’est très pratique
pour analyser de nouveaux protocoles. Dans l'implémentation actuelle,
cet indicateur peut avoir le même effet que -XX si le paquet est tronqué.

-XX
Lors de l'analyse et de l'impression, en plus d'imprimer les en-têtes de
chaque paquet, imprimez les données de chaque paquet, y compris son
en-tête au niveau du lien, en hexadécimal et ASCII.

-y type de liaison de données

--linktype= type de lien de données
Définissez le type de liaison de données à utiliser lors de la capture des
paquets (voir -L ) ou simplement en compilant et en vidant le code de
correspondance de paquets (voir -d ) vers datalinktype .

-z commande-postrotation
Utilisé conjointement avec les options -C ou -G , cela
obligera tcpdump à exécuter " postrotate-command file " où file est le
fichier de sauvegarde fermé après chaque rotation. Par exemple,
spécifier -z gzip ou -z bzip2 compressera chaque fichier de sauvegarde
à l'aide de gzip ou bzip2.

Notez que tcpdump exécutera la commande parallèlement à la capture,

en utilisant la priorité la plus basse afin que cela ne perturbe pas le
processus de capture.

Et si vous souhaitez utiliser une commande qui elle-même prend des

indicateurs ou des arguments différents, vous pouvez toujours écrire un
script shell qui prendra le nom du fichier de sauvegarde comme seul
argument, organisera les indicateurs et arguments et exécutera la
commande de votre choix.

-Z utilisateur
--relinquish-privileges= utilisateur
Si tcpdump s'exécute en tant qu'utilisateur root, après avoir ouvert le
périphérique de capture ou le fichier de sauvegarde d'entrée, mais
 avant d'ouvrir un fichier de sauvegarde pour la sortie, remplacez l'ID
utilisateur par user et l'ID de groupe par le groupe principal d' user .

Ce comportement peut également être activé par défaut au moment de

la compilation.

expression
sélectionne les paquets qui seront vidés. Si aucune expression n'est
donnée, tous les paquets sur le réseau seront vidés. Sinon, seuls les
paquets pour lesquels l'expression est « true » seront vidés.

Pour la syntaxe de l'expression , voir pcap-filter (7) .

L' argument expression peut être transmis à tcpdump soit comme un

seul argument Shell, soit comme plusieurs arguments Shell, selon ce
qui est le plus pratique. Généralement, si l'expression contient des
métacaractères Shell, tels que des barres obliques inverses utilisées
pour échapper aux noms de protocole, il est plus facile de la transmettre
sous la forme d'un argument unique entre guillemets plutôt que
d'échapper aux métacaractères Shell. Plusieurs arguments sont
concaténés avec des espaces avant d'être analysés.

EXEMPLES
Pour imprimer tous les paquets arrivant ou partant du coucher du soleil :

coucher du soleil de l'hôte tcpdump

Pour imprimer le trafic entre Helios et Hot ou Ace :

tcpdump hôte helios et \( hot ou as \)

Pour imprimer tous les paquets IP entre ace et n'importe quel hôte
sauf helios :

tcpdump ip host as et non helios

Pour imprimer tout le trafic entre les hôtes locaux et les hôtes à Berkeley :

tcpdump net ucb-éther

Pour imprimer tout le trafic ftp via la passerelle Internet snup : (notez que
l'expression est citée pour empêcher le shell d'interpréter (mal) les
parenthèses) :

tcpdump 'coupure de passerelle et (port

ftp ou ftp-data)'
Pour imprimer le trafic qui ne provient ni n'est destiné à des hôtes locaux (si
vous passez à un autre réseau, ces éléments ne devraient jamais arriver sur
votre réseau local).

tcpdump ip et pas net localnet

Pour imprimer les paquets de début et de fin (les paquets SYN et FIN) de
chaque conversation TCP impliquant un hôte non local.

tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-

fin) != 0 et non src et dst net
localnet '
Pour imprimer les paquets TCP avec les indicateurs RST et ACK tous deux
définis. (c'est-à-dire, sélectionnez uniquement les indicateurs RST et ACK
dans le champ des indicateurs, et si le résultat est "RST et ACK tous les deux
définis", faites correspondre)

tcpdump 'tcp[tcpflags] & (tcp-rst|tcp-

ack) == (tcp-rst|tcp-ack)'
Pour imprimer tous les paquets HTTP IPv4 vers et depuis le port 80, c'est-à-
dire imprimer uniquement les paquets contenant des données, pas, par
exemple, les paquets SYN et FIN et les paquets ACK uniquement. (IPv6 est
laissé comme exercice au lecteur.)

tcpdump 'port TCP 80 et (((ip[2:2] -

((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2))
!= 0)'
Pour imprimer les paquets IP de plus de 576 octets envoyés via la
passerelle snup :

tcpdump 'coupure de passerelle et

ip[2:2] > 576'
Pour imprimer des paquets de diffusion IP ou de multidiffusion qui n'ont
pas été envoyés via la diffusion Ethernet ou la multidiffusion :

tcpdump 'ether[0] & 1 = 0 et ip[16] >=

224'
Pour imprimer tous les paquets ICMP qui ne sont pas des
demandes/réponses d'écho (c'est-à-dire des paquets ping) :

tcpdump 'icmp[icmptype] != icmp-echo et

icmp[icmptype] != icmp-echoreply'
FORMAT DE SORTIE
La sortie de tcpdump dépend du protocole. Ce qui suit donne une brève
description et des exemples de la plupart des formats.

Horodatages

Par défaut, toutes les lignes de sortie sont précédées d'un

horodatage. L'horodatage est l'heure actuelle sous la forme

hh:mm:ss.frac
et est aussi précis que l'horloge du noyau. L'horodatage reflète l'heure à
laquelle le noyau a appliqué un horodatage au paquet. Aucune tentative n'est
faite pour tenir compte du décalage temporel entre le moment où l'interface
réseau a fini de recevoir le paquet du réseau et le moment où le noyau a
appliqué un horodatage au paquet ; ce décalage temporel pourrait inclure un
délai entre le moment où l'interface réseau a fini de recevoir un paquet du
réseau et le moment où une interruption a été délivrée au noyau pour
l'amener à lire le paquet et un délai entre le moment où le noyau a traité le
paquet. l'interruption du « nouveau paquet » et l'heure à laquelle elle a
appliqué un horodatage au paquet.
Interface
Lorsque n'importe quelle interface est sélectionnée lors de la capture ou
lorsqu'un fichier de capture LINUX_SLL2 de type lien est lu, le nom de
l'interface est imprimé après l'horodatage. Ceci est suivi du type de
paquet, In et Out désignant respectivement un paquet destiné à cet hôte ou
provenant de cet hôte. D'autres valeurs possibles sont B pour les paquets de
diffusion, M pour les paquets de multidiffusion et P pour les paquets destinés
à d'autres hôtes.

En-têtes de niveau de lien

Si l'option '-e' est donnée, l'en-tête au niveau du lien est imprimé. Sur
Ethernet, les adresses source et de destination, le protocole et la longueur
des paquets sont imprimés.

Sur les réseaux FDDI, l'option '-e' amène tcpdump à imprimer le champ 'frame
control', les adresses source et de destination, ainsi que la longueur du
paquet. (Le champ « contrôle de trame » régit l'interprétation du reste du
paquet. Les paquets normaux (tels que ceux contenant des datagrammes IP)
sont des paquets « asynchrones », avec une valeur de priorité comprise entre
0 et 7 ; par exemple, « async4 » . les paquets sont supposés contenir un
paquet LLC (Logical Link Control) 802.2 ; l'en-tête LLC est imprimé s'il ne
s'agit pas d'un datagramme ISO ou d'un paquet dit SNAP.

Sur les réseaux Token Ring, l'option '-e' amène tcpdump à imprimer les
champs 'access control' et 'frame control', les adresses source et de
destination, ainsi que la longueur du paquet. Comme sur les réseaux FDDI,
les paquets sont supposés contenir un paquet LLC. Que l'option « -e » soit
spécifiée ou non, les informations de routage source sont imprimées pour les
paquets routés par la source.

Sur les réseaux 802.11, l'option '-e' amène tcpdump à imprimer les champs
'frame control', toutes les adresses dans l'en-tête 802.11 et la longueur du
paquet. Comme sur les réseaux FDDI, les paquets sont supposés contenir un
paquet LLC.

(NB : la description suivante suppose une connaissance de l'algorithme de

compression SLIP décrit dans la RFC 1144.)
Sur les liaisons SLIP, un indicateur de direction (« I » pour entrant, « O » pour
sortant), le type de paquet et les informations de compression sont
imprimés. Le type de paquet est imprimé en premier. Les trois types
sont ip , utcp et ctcp . Aucune autre information de lien n'est imprimée pour
les paquets IP . Pour les paquets TCP, l'identifiant de connexion est imprimé
après le type. Si le paquet est compressé, son en-tête codé est imprimé. Les
cas particuliers sont imprimés sous la forme *S+ n et *SA+ n , où n est la
quantité de modification du numéro de séquence (ou du numéro de séquence
et de l'accusé de réception). S'il ne s'agit pas d'un cas particulier, aucune ou
plusieurs modifications ne sont imprimées. Un changement est indiqué par U
(pointeur urgent), W (fenêtre), A (ack), S (numéro de séquence) et I (ID de
paquet), suivis d'un delta (+n ou -n) ou d'une nouvelle valeur. (=n). Enfin, la
quantité de données contenues dans le paquet et la longueur de l'en-tête
compressé sont imprimées.

Par exemple, la ligne suivante montre un paquet TCP compressé sortant,

avec un identifiant de connexion implicite ; l'accusé de réception a changé de
6, le numéro de séquence de 49 et l'ID du paquet de 6 ; il y a 3 octets de
données et 6 octets d'en-tête compressé :

O ctcp * A+6 S+49 I+6 3 (6)

Paquets ARP/RARP

La sortie ARP/RARP affiche le type de requête et ses arguments. Le format

se veut explicite. Voici un court échantillon pris au début d'un `rlogin' de
l'hôte rtsg vers l'hôte csam :

arp qui a csam dis à rtsg

arp réponse csam est-à CSAM

La première ligne indique que rtsg a envoyé un paquet ARP demandant

l'adresse Ethernet de l'hôte Internet csam. Csam répond avec son adresse
Ethernet (dans cet exemple, les adresses Ethernet sont en majuscules et les
adresses internet en minuscules).

Cela semblerait moins redondant si nous avions fait tcpdump -n :

 arp qui a 128.3.254.6 dit 128.3.254.68
la réponse arp 128.3.254.6 est à
02:07:01:00:01:c4
Si nous avions fait tcpdump -e , le fait que le premier paquet soit diffusé et le
second point à point serait visible :

Diffusion RTSG 0806 64 : arp qui a csam,

dites au rtsg
CSAM RTSG 0806 64 : réponse arp csam est
sur CSAM

Pour le premier paquet, cela indique que l'adresse source Ethernet est RTSG,
la destination est l'adresse de diffusion Ethernet, le champ de type contenait
l'hexagone 0806 (type ETHER_ARP) et la longueur totale était de 64 octets.
Paquets IPv4

Si l'en-tête de couche liaison n'est pas imprimé, pour les paquets

IPv4, l'adresse IP est imprimée après l'horodatage.

Si l' indicateur -v est spécifié, les informations de l'en-tête IPv4 sont affichées
entre parenthèses après l' adresse IP ou l'en-tête de couche liaison. Le
format général de ces informations est le suivant :

tos tos , ttl ttl , id id , offset

offset , drapeaux [ drapeaux ], proto
proto , longueur longueur , options (
options )

tos est le type de champ de service ; si les bits ECN sont différents de zéro,
ceux-ci sont signalés comme ECT(1) , ECT(0) ou CE . ttl est la durée de
vie ; il n'est pas signalé s'il est nul. id est le champ d'identification IP. offset est
le champ de décalage du fragment ; il est imprimé, qu'il fasse ou non partie
d'un datagramme fragmenté. les drapeaux sont les drapeaux MF et DF ; + est
signalé si MF est défini, et DF est signalé si F est défini. Si aucun des deux
n’est défini, . est signalé. proto est le champ ID du protocole. length est le
champ de longueur totale ; si le paquet est un envoi TSO (TCP Segmentation
Offload) présumé, [était 0, TSO présumé] est signalé. les options sont les
options IP, le cas échéant.

Ensuite, pour les paquets TCP et UDP, les adresses IP source et destination
et les ports TCP ou UDP, avec un point entre chaque adresse IP et son port
correspondant, seront imprimés, avec un > séparant la source et la
destination. Pour les autres protocoles, les adresses seront imprimées, avec
un > séparant la source et la destination. Les informations de protocole de
niveau supérieur, le cas échéant, seront imprimées par la suite.

Pour les datagrammes IP fragmentés, le premier fragment contient l'en-tête

de protocole de niveau supérieur ; les fragments après le premier ne
contiennent aucun en-tête de protocole de niveau supérieur. Les informations
de fragmentation seront imprimées uniquement avec l' indicateur -v , dans les
informations d'en-tête IP, comme décrit ci-dessus.

Paquets TCP

(NB : la description suivante suppose une connaissance du protocole TCP

décrit dans la RFC 793. Si vous n'êtes pas familier avec le protocole, cette
description ne vous sera pas d'une grande utilité.)

Le format général d'une ligne de protocole TCP est :

src > dst : indicateurs [ tcpflags ],

seq data-seqno , ack ackno , win
window , urg urgent , options [ opts ],
longueur len

Src et dst sont les adresses IP et les ports source et destination. Les
Tcpflags sont une combinaison de S (SYN), F (FIN), P (PSH), R (RST), U
(URG), W (CWR), E (ECE) ou `.' (ACK), ou `none' si aucun indicateur n'est
défini. Data-seqno décrit la partie de l'espace de séquence couverte par les
données de ce paquet (voir exemple ci-dessous). Ackno est le numéro de
séquence des données suivantes attendues dans l'autre sens sur cette
connexion. Window est le nombre d'octets d'espace tampon de réception
disponible dans l'autre sens sur cette connexion. Urg indique qu'il y a des
données « urgentes » dans le paquet. Les opts sont des options TCP (par
exemple, mss 1024). Len est la longueur des données de charge utile.

Iptype , Src , dst et les drapeaux sont toujours présents. Les autres champs
dépendent du contenu de l'en-tête du protocole TCP du paquet et ne sont
affichés que si cela est approprié.

Voici la partie d'ouverture d'un rlogin de l'hôte rtsg à l'hôte csam .

IP rtsg.1023 > csam.login : Flags [S],

seq 768512:768512, win 4096, opte [mss
1024]
IP csam.login > rtsg.1023 : Flags [S.],
seq, 947648:947648, ack 768513, win
4096, opte [mss 1024]
IP rtsg.1023 > csam.login : indicateurs
[.], accusé de réception 1, victoire
4096
IP rtsg.1023 > csam.login : Flags [P.],
séquence 1:2, accusé de réception 1,
victoire 4096, longueur 1
IP csam.login > rtsg.1023 : indicateurs
[.], accusé de réception 2, victoire
4096
IP rtsg.1023 > csam.login : Flags [P.],
séquence 2:21, accusé de réception 1,
victoire 4096, longueur 19
IP csam.login > rtsg.1023 : Flags [P.],
séquence 1:2, accusé de réception 21,
victoire 4077, longueur 1
 IP csam.login > rtsg.1023 : Flags [P.],
séquence 2:3, accusé de réception 21,
victoire 4077, urg 1, longueur 1
IP csam.login > rtsg.1023 : Flags [P.],
séquence 3:4, accusé de réception 21,
victoire 4077, urg 1, longueur 1

La première ligne indique que le port TCP 1023 sur rtsg a envoyé un paquet
au port de connexion sur csam. Le S indique que le drapeau SYN a été
activé. Le numéro de séquence du paquet était 768512 et ne contenait
aucune donnée. (La notation est « premier:dernier », ce qui signifie «
numéros de séquence du premier au dernier mais non compris ».) Il n'y avait
pas d'ACK superposé, la fenêtre de réception disponible était de 4 096 octets
et il y avait une option de taille de segment maximale demandant un MSS de
1024 octets.

Csam répond avec un paquet similaire, sauf qu'il inclut un ACK superposé
pour le SYN de rtsg. Rtsg accuse ensuite SYN de csam. Le « . » signifie que
l'indicateur ACK a été défini. Le paquet ne contenait aucune donnée, il n'y a
donc ni numéro de séquence ni longueur de données. Notez que le numéro
de séquence ACK est un petit entier (1). La première fois que tcpdump voit
une « conversation » TCP, il imprime le numéro de séquence du paquet. Sur
les paquets suivants de la conversation, la différence entre le numéro de
séquence du paquet actuel et ce numéro de séquence initial est
imprimée. Cela signifie que les numéros de séquence après le premier
peuvent être interprétés comme des positions relatives d'octets dans le flux de
données de la conversation (le premier octet de données dans chaque
direction étant « 1 »). `-S' remplacera cette fonctionnalité, provoquant la sortie
des numéros de séquence d'origine.

Sur la 6ème ligne, rtsg envoie à csam 19 octets de données (octets 2 à 20 du

côté rtsg → csam de la conversation). L'indicateur PSH est défini dans le
paquet. Sur la 7ème ligne, csam indique qu'il a reçu des données envoyées
par rtsg jusqu'à l'octet 21 mais sans l'inclure. La plupart de ces données se
trouvent apparemment dans le tampon de socket puisque la fenêtre de
réception de csam a été réduite de 19 octets. Csam envoie également un
octet de données à rtsg dans ce paquet. Sur les 8ème et 9ème lignes, csam
envoie deux octets de données urgentes et poussées à rtsg.
Si l'instantané était suffisamment petit pour que tcpdump n'ait pas capturé
l'en-tête TCP complet, il interprète autant d'en-tête que possible et rapporte
ensuite ``[| tcp ]'' pour indiquer que le reste n'a pas pu être interprété. Si l'en-
tête contient une fausse option (une avec une longueur trop petite ou au-delà
de la fin de l'en-tête), tcpdump la signale comme ``[ bad opt ]'' et n'interprète
aucune autre option (puisqu'il est impossible de le savoir). où ils
commencent). Si la longueur de l'en-tête indique que des options sont
présentes mais que la longueur du datagramme IP n'est pas assez longue
pour que les options soient réellement là, tcpdump le signale comme
« [ mauvaise longueur hdr ] ».

Combinaisons particulières d'indicateurs TCP (SYN-ACK, URG-ACK,

etc.)

Il y a 8 bits dans la section des bits de contrôle de l'en-tête TCP :

CWR | CEE | URG | ACK | PSH | TVD | SYN | AILETTE

Supposons que nous souhaitions surveiller les paquets utilisés pour établir
une connexion TCP. Rappelez-vous que TCP utilise un protocole de
négociation à trois voies lorsqu'il initialise une nouvelle connexion ; la
séquence de connexion concernant les bits de contrôle TCP est

1) L'appelant envoie SYN

2) Le destinataire répond par SYN, ACK

3) L'appelant envoie un ACK

Nous souhaitons maintenant capturer les paquets dont seul le bit SYN est
défini (étape 1). Notez que nous ne voulons pas de paquets de l'étape 2
(SYN-ACK), juste un simple SYN initial. Ce dont nous avons besoin, c'est
d'une expression de filtre correcte pour tcpdump .

Rappelez-vous la structure d'un en-tête TCP sans options :

0 15 31
-------------------------------------------
------- ---------------
| port source | port de destination |
-------------------------------------------
------- ---------------
| numéro de séquence |
-------------------------------------------
------- ---------------
| numéro d'accusé de réception |
-------------------------------------------
------- ---------------
| HL | rsvd |C|E|U|A|P|R|S|F| taille de la
fenêtre |
-------------------------------------------
------- ---------------
| Somme de contrôle TCP | pointeur urgent |
-------------------------------------------
------- ---------------
Un en-tête TCP contient généralement 20 octets de données, sauf si des
options sont présentes. La première ligne du graphique contient les octets 0 à
3, la deuxième ligne affiche les octets 4 à 7, etc.

En commençant par 0, les bits de contrôle TCP pertinents sont contenus dans
l'octet 13 :

0 7| 15| 23| 31
----------------|---------------|----------
-----|- ---------------
| HL | rsvd |C|E|U|A|P|R|S|F| taille de la
fenêtre |
----------------|---------------|----------
-----|- ---------------
| | 13ème octet | | |
Regardons de plus près l'octet no. 13 :
 | |
|---------------|
|C|E|U|A|P|R|S|F|
|---------------|
|7 5 3 0|
Ce sont les bits de contrôle TCP qui nous intéressent. Nous avons numéroté
les bits de cet octet de 0 à 7, de droite à gauche, le bit PSH est donc le bit
numéro 3, tandis que le bit URG est le numéro 5.

Rappelez-vous que nous voulons capturer des paquets avec uniquement le

jeu SYN. Voyons ce qui arrive à l'octet 13 si un datagramme TCP arrive avec
le bit SYN défini dans son en-tête :

|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 0 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
En regardant la section des bits de contrôle, nous voyons que seul le bit
numéro 1 (SYN) est défini.

En supposant que l'octet numéro 13 est un entier non signé de 8 bits dans
l'ordre des octets du réseau, la valeur binaire de cet octet est

00000010

et sa représentation décimale est

7 6 5 4 3 2 1 0
0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 +
0*2 = 2
Nous avons presque terminé, car nous savons maintenant que si seul SYN
est défini, la valeur du 13ème octet dans l'en-tête TCP, lorsqu'il est interprété
comme un entier non signé de 8 bits dans l'ordre des octets du réseau, doit
être exactement 2.

Cette relation peut être exprimée comme

tcp[13] == 2

Nous pouvons utiliser cette expression comme filtre pour tcpdump afin de
surveiller les paquets pour lesquels seul SYN est défini :

tcpdump -i xl0 'tcp[13] == 2'

L'expression dit "laissez le 13ème octet d'un datagramme TCP avoir la valeur
décimale 2", ce qui est exactement ce que nous voulons.

Supposons maintenant que nous devions capturer les paquets SYN, mais peu
nous importe si ACK ou tout autre bit de contrôle TCP est défini en même
temps. Voyons ce qui arrive à l'octet 13 lorsqu'un datagramme TCP avec
SYN-ACK défini arrive :

|C|E|U|A|P|R|S|F|
|---------------|
|0 0 0 1 0 0 1 0|
|---------------|
|7 6 5 4 3 2 1 0|
Les bits 1 et 4 sont désormais définis dans le 13ème octet. La valeur binaire
de l'octet 13 est

00010010

ce qui se traduit par décimal

7 6 5 4 3 2 1 0
0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 +
0*2 = 18
Maintenant, nous ne pouvons pas simplement utiliser 'tcp[13] == 18' dans l'
expression du filtre tcpdump , car cela sélectionnerait uniquement les paquets
pour lesquels SYN-ACK est défini, mais pas ceux avec uniquement SYN
défini. N'oubliez pas que nous ne nous soucions pas de savoir si ACK ou tout
autre bit de contrôle est défini tant que SYN est défini.

Afin d'atteindre notre objectif, nous devons logiquement ET la valeur binaire

de l'octet 13 avec une autre valeur pour préserver le bit SYN. Nous savons
que nous voulons que SYN soit défini dans tous les cas, nous allons donc
logiquement ET la valeur dans le 13ème octet avec la valeur binaire d'un
SYN :

00010010 SYN-ACK 00000010 SYN

AND 00000010 (nous voulons SYN) AND
00000010 (nous voulons SYN)
-------- --------
= 00000010 = 00000010
Nous voyons que cette opération AND donne le même résultat, que ACK ou
un autre bit de contrôle TCP soit défini. La représentation décimale de la
valeur AND ainsi que le résultat de cette opération est 2 (binaire 00000010),
nous savons donc que pour les paquets avec SYN défini, la relation suivante
doit être vraie :

( (valeur de l'octet 13 ) AND ( 2 ) ) == ( 2 )

Cela nous renvoie à l' expression du filtre tcpdump

tcpdump -i xl0 'tcp[13] & 2 == 2'

Certains décalages et valeurs de champ peuvent être exprimés sous forme de

noms plutôt que de valeurs numériques. Par exemple, tcp[13] peut être
remplacé par tcp[tcpflags]. Les valeurs de champ d'indicateur TCP suivantes
sont également disponibles : tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-
urg, tcp-ece et tcp-cwr.
Cela peut être démontré comme suit :

tcpdump -i xl0 'tcp[tcpflags] & tcp-push != 0'

Notez que vous devez utiliser des guillemets simples ou une barre oblique
inverse dans l'expression pour masquer le caractère spécial AND ('&') du
shell.

Paquets UDP

Le format UDP est illustré par ce paquet rwho :

actinide.who > diffusion.who : udp 84

Cela indique que le port qui sur l'hôte actinide a envoyé un datagramme UDP
au port qui sur l'hôte a diffusé , l'adresse de diffusion Internet. Le paquet
contenait 84 octets de données utilisateur.

Certains services UDP sont reconnus (à partir du numéro de port source ou

de destination) et les informations de protocole de niveau supérieur sont
imprimées. En particulier, les demandes de service de nom de domaine (RFC
1034/1035) et les appels Sun RPC (RFC 1050) vers NFS.

Requêtes de serveur de noms TCP ou UDP

(NB : la description suivante suppose une connaissance du protocole de

service de domaine décrit dans la RFC 1035. Si vous n'êtes pas familier avec
le protocole, la description suivante semblera être écrite en grec.)

Les requêtes du serveur de noms sont formatées comme suit :

src > dst : identifiant op ? flags

qtype nom de qclass (len)
 h2opolo.1538 > helios.domain : 3+ A ?
ucbvax.berkeley.edu. (37)

L'hôte h2opolo a demandé au serveur de domaine sur helios un

enregistrement d'adresse (qtype=A) associé au
nom ucbvax.berkeley.edu. L'identifiant de la requête était « 3 ». Le «+»
indique que l'indicateur de récursion souhaité a été défini. La longueur de la
requête était de 37 octets, à l'exclusion des en-têtes de protocole TCP ou
UDP et IP. L'opération de requête était l'opération normale, Query , donc le
champ op a été omis. Si l'opération avait été autre chose, elle aurait été
imprimée entre le « 3 » et le « + ». De même, la classe q était la classe
normale, C_IN , et a été omise. Toute autre classe q aurait été imprimée
immédiatement après le « A ».

Quelques anomalies sont vérifiées et peuvent entraîner des champs

supplémentaires entre crochets : Si une requête contient une réponse, les
notices d'autorité ou la section de notices supplémentaires, ancount ,
nscount ou arcount sont imprimées sous la forme `[ n a]', `[ n n ]' ou `[ n au]'
où n est le nombre approprié. Si l'un des bits de réponse est défini (AA, RA ou
rcode) ou si l'un des bits « doit être zéro » est défini dans les octets deux et
trois, « [b2&3= x ] » est imprimé, où x est la valeur hexadécimale de octets
d'en-tête deux et trois.

Réponses du serveur de noms TCP ou UDP

Les réponses du serveur de noms sont formatées comme suit :

src > dst : id op rcode flags a/n/au

type class data (len)

helios.domain > h2opolo.1538 : 3 3/3/7 A

128.32.137.3 (273)
helios.domain > h2opolo.1537 : 2
NXDomain* 0/1/0 (97)
Dans le premier exemple, helios répond à l'identifiant de requête 3
de h2opolo avec 3 enregistrements de réponse, 3 enregistrements de serveur
de noms et 7 enregistrements supplémentaires. Le premier enregistrement de
réponse est de type A (adresse) et ses données sont l'adresse Internet
128.32.137.3. La taille totale de la réponse était de 273 octets, hors en-têtes
TCP ou UDP et IP. L'opération (Query) et le code de réponse (NoError) ont
été omis, tout comme la classe (C_IN) de l'enregistrement A.

Dans le deuxième exemple, helios répond à la requête 2 avec un code de

réponse de domaine inexistant (NXDomain) sans réponse, un serveur de
noms et aucune notice d'autorité. Le « * » indique que le bit de réponse
faisant autorité a été activé. Puisqu’il n’y avait pas de réponses, aucun type,
classe ou donnée n’a été imprimé.

Les autres caractères d'indicateur qui peuvent apparaître sont `-' (récursion
disponible, RA, non défini) et `|' (message tronqué, TC, set). Si la section
`question' ne contient pas exactement une entrée, `[ n q]' est imprimé.

Décodage SMB/CIFS

tcpdump inclut désormais un décodage SMB/CIFS/NBT assez étendu pour

les données sur UDP/137, UDP/138 et TCP/139. Un décodage primitif des
données IPX et NetBEUI SMB est également effectué.

Par défaut, un décodage assez minimal est effectué, avec un décodage

beaucoup plus détaillé si -v est utilisé. Soyez averti qu'avec -va, un seul
paquet SMB peut occuper une page ou plus, alors n'utilisez -v que si vous
voulez vraiment tous les détails sanglants.

Pour plus d'informations sur les formats de paquets SMB et la signification de

tous les champs, consultez https://download.samba.org/pub/samba/specs/ et
d'autres ressources en ligne. Les correctifs SMB ont été écrits par Andrew
Tridgell (tridge@samba.org).

Requêtes et réponses NFS

Les requêtes et réponses Sun NFS (Network File System) sont imprimées
comme suit :
 src.sport > dst.nfs : requête NFS xid
xid len op args
src.nfs > dst.dport : réponse NFS xid
xid réponse stat len op résultats

sushi.1023 > wrl.nfs : requête NFS xid

26377
112 lien de lecture fh
21,24/10.73165
wrl.nfs > sushi.1023 : réponse NFS xid
26377
réponse ok 40 readlink "../var"
sushi.1022 > wrl.nfs : requête NFS xid
8219
144 recherche fh 9,74/4096.6878
"xcolors"
wrl.nfs > sushi.1022 : réponse NFS xid
8219
réponse ok 128 recherche fh
9,74/4134.3150

Dans la première ligne, l'hôte sushi envoie une transaction avec

l'identifiant 26377 à wrl . La requête faisait 112 octets, sans compter les en-
têtes UDP et IP. L'opération était un lien de lecture (lien symbolique de
lecture) sur le descripteur de fichier ( fh ) 21,24/10.731657119. (Si l'on a de la
chance, comme dans ce cas, le descripteur de fichier peut être interprété
comme une paire de numéros de périphérique majeur et mineur, suivi du
numéro d'inode et du numéro de génération.) Dans la deuxième ligne, wrl
répond « ok » avec la même transaction . identifiant et le contenu du lien.

Dans la troisième ligne, sushi demande (en utilisant un nouvel identifiant de

transaction) à wrl de rechercher le nom ` xcolors ' dans le fichier répertoire
9,74/4096.6878. Dans la quatrième ligne, wrl envoie une réponse avec
l'identifiant de transaction respectif.

Notez que les données imprimées dépendent du type d’opération. Le format

est censé être explicite s'il est lu conjointement avec une spécification de
protocole NFS. Notez également que les anciennes versions de tcpdump
imprimaient les paquets NFS dans un format légèrement différent : l'identifiant
de transaction (xid) serait imprimé à la place du numéro de port non NFS du
paquet.

Si l'indicateur -v (verbeux) est donné, des informations supplémentaires sont

imprimées. Par exemple:

sushi.1023 > wrl.nfs : requête NFS xid

79658
148 lectures fh 21,11/12,195
8 192 octets à 24 576
wrl.nfs > sushi.1023 : réponse NFS xid
79658
réponse ok 1472 lire REG 100664
ids 417/0 sz 29388

(-v imprime également les champs TTL, ID, longueur et fragmentation de l'en-
tête IP, qui ont été omis de cet exemple.) Dans la première
ligne, sushi demande à wrl de lire 8 192 octets du fichier 21,11/12.195, au
décalage d'octets. 24576. Wrl répond « ok » ; le paquet affiché sur la
deuxième ligne est le premier fragment de la réponse, et ne fait donc que
1472 octets (les autres octets suivront dans les fragments suivants, mais ces
fragments n'ont pas d'en-têtes NFS ou même UDP et pourraient donc ne pas
être imprimés, selon l'expression de filtre utilisée). Parce que l'option -v est
donnée, certains attributs du fichier (qui sont retournés en plus des données
du fichier) sont imprimés : le type de fichier ("REG", pour fichier normal), le
mode de fichier (en octal), l'UID et le GID, ainsi que la taille du fichier.
Si l'indicateur -v est donné plus d'une fois, encore plus de détails sont
imprimés.

Les paquets de réponse NFS n'identifient pas explicitement l'opération

RPC. Au lieu de cela, tcpdump garde une trace des requêtes « récentes » et
les fait correspondre aux réponses en utilisant l'ID de transaction. Si une
réponse ne suit pas de près la requête correspondante, elle risque de ne pas
être analysable.

Demandes et réponses AFS

Les requêtes et réponses Transarc AFS (Andrew File System) sont imprimées
comme :

src.sport > dst.dport : type de paquet

rx
src.sport > dst.dport : argument de nom
d'appel d'appel de service de type
paquet rx
src.sport > dst.dport : argument de nom
d'appel de réponse de service de type
paquet rx

elvis.7001 > pike.afsfs :

rx data fs call renommer
l'ancien fid 536876964/1/1 ".newsrc.new"
nouveau fid 536876964/1/1
".newsrc"
pike.afsfs > elvis.7001 : renommer la
réponse fs des données rx
Sur la première ligne, l'hôte Elvis envoie un paquet RX à Pike. Il s'agissait
d'un paquet de données RX destiné au service fs (serveur de fichiers) et
constitue le début d'un appel RPC. L'appel RPC était un changement de nom,
avec l'ancien identifiant de fichier de répertoire de 536876964/1/1 et un ancien
nom de fichier de `.newsrc.new', et un nouvel identifiant de fichier de
répertoire de 536876964/1/1 et un nouveau nom de fichier de `.
newsrc'. L'hôte Pike répond par une réponse RPC à l'appel de renommage
(qui a réussi, car il s'agissait d'un paquet de données et non d'un paquet
d'abandon).

En général, tous les RPC AFS sont décodés au moins par nom d'appel
RPC. La plupart des RPC AFS ont au moins certains des arguments décodés
(généralement uniquement les arguments « intéressants », pour une certaine
définition d'intéressant).

Le format est censé être auto-descriptif, mais il ne sera probablement pas

utile aux personnes qui ne connaissent pas le fonctionnement d'AFS et RX.

Si l'indicateur -v (verbeux) est donné deux fois, les paquets d'accusé de

réception et des informations d'en-tête supplémentaires sont imprimés, telles
que l'ID d'appel RX, le numéro d'appel, le numéro de séquence, le numéro de
série et les indicateurs de paquet RX.

Si l'indicateur -v est donné deux fois, des informations supplémentaires sont

imprimées, telles que l'ID d'appel RX, le numéro de série et les indicateurs de
paquet RX. Les informations de négociation MTU sont également imprimées
à partir des paquets RX ack.

Si l'indicateur -v est donné trois fois, l'index de sécurité et l'identifiant du

service sont imprimés.

Des codes d'erreur sont imprimés pour les paquets d'abandon, à l'exception
des paquets de balise Ubik (car les paquets d'abandon sont utilisés pour
signifier un vote oui pour le protocole Ubik).

Les paquets de réponse AFS n'identifient pas explicitement l'opération

RPC. Au lieu de cela, tcpdump garde une trace des requêtes « récentes » et
les associe aux réponses en utilisant le numéro d'appel et l'ID de service. Si
une réponse ne suit pas de près la requête correspondante, elle risque de ne
pas être analysable.
KIP AppleTalk (DDP en UDP)

Les paquets AppleTalk DDP encapsulés dans les datagrammes UDP sont
désencapsulés et vidés en tant que paquets DDP (c'est-à-dire que toutes les
informations d'en-tête UDP sont supprimées). Le fichier /etc/atalk.names est
utilisé pour traduire les numéros de réseau et de nœud AppleTalk en
noms. Les lignes de ce fichier ont la forme

nom du numéro

1,254 éther
16.1 icsd-net
1.254.110 as

Les deux premières lignes donnent les noms des réseaux AppleTalk. La
troisième ligne donne le nom d'un hôte particulier (un hôte se distingue d'un
réseau par le 3ème octet du numéro - un numéro de réseau doit avoir deux
octets et un numéro d'hôte doit avoir trois octets.) Le numéro et le nom
doivent être séparés. par espaces (blancs ou tabulations). Le
fichier /etc/atalk.names peut contenir des lignes vides ou des lignes de
commentaires (lignes commençant par un `#').

Les adresses AppleTalk sont imprimées sous la forme

net.host.port

144.1.209.2 > icsd-net.112.220

office.2 > icsd-net.112.220
jssmag.149.235 > icsd-net.2

(Si le fichier /etc/atalk.names n'existe pas ou ne contient pas d'entrée pour un

numéro d'hôte/réseau AppleTalk, les adresses sont imprimées sous forme
numérique.) Dans le premier exemple, NBP (port DDP 2) sur le réseau 144.1
le nœud 209 envoie à tout ce qui écoute sur le port 220 du nœud net icsd
112. La deuxième ligne est la même sauf que le nom complet du nœud
source est connu (« bureau »). La troisième ligne est un envoi depuis le port
235 sur le nœud net jssmag 149 pour diffuser sur le port icsd-net NBP (notez
que l'adresse de diffusion (255) est indiquée par un nom de réseau sans
numéro d'hôte - pour cette raison, c'est une bonne idée pour garder les noms
de nœuds et les noms de réseau distincts dans /etc/atalk.names).

Les paquets NBP (Name Binding Protocol) et ATP (AppleTalk Transaction

Protocol) voient leur contenu interprété. D'autres protocoles sauvegardent
simplement le nom du protocole (ou le numéro si aucun nom n'est enregistré
pour le protocole) et la taille du paquet.

Paquets NBP
Les paquets NBP sont formatés comme dans les exemples suivants :

icsd-net.112.220 > jssmag.2 : nbp-lkup

190 : "=:LaserWriter@*"
jssmag.209.2 > icsd-net.112.220 :
réponse nbp 190 : "RM1140:LaserWriter@*"
250
techpit.2 > icsd-net.112.220 : nbp-reply
190 : "techpit:LaserWriter@*" 186

La première ligne est une demande de recherche de nom pour les écrivains
laser envoyée par l'hôte net icsd 112 et diffusée sur net jssmag. L'identifiant
nbp pour la recherche est 190. La deuxième ligne affiche une réponse à cette
requête (notez qu'elle a le même identifiant) de l'hôte jssmag.209 indiquant
qu'il dispose d'une ressource laserwriter nommée "RM1140" enregistrée sur le
port 250. La troisième line est une autre réponse à la même demande
indiquant que le techpit hôte a un graveur laser "techpit" enregistré sur le port
186.
Paquets ATP
Le formatage des paquets ATP est illustré par l'exemple suivant :

jssmag.209.165 > helios.132 : atp-req

12266<0-7> 0xae030001
helios.132 > jssmag.209.165 : atp-resp
12266:0 (512) 0xae040000
 helios.132 > jssmag.209.165 : atp-resp
12266:1 (512) 0xae040000
helios.132 > jssmag.209.165 : atp-resp
12266:2 (512) 0xae040000
helios.132 > jssmag.209.165 : atp-resp
12266:3 (512) 0xae040000
helios.132 > jssmag.209.165 : atp-resp
12266:4 (512) 0xae040000
helios.132 > jssmag.209.165 : atp-resp
12266:5 (512) 0xae040000
helios.132 > jssmag.209.165 : atp-resp
12266:6 (512) 0xae040000
helios.132 > jssmag.209.165 : atp-
resp*12266:7 (512) 0xae040000
jssmag.209.165 > helios.132 : atp-req
12266<3,5> 0xae030001
helios.132 > jssmag.209.165 : atp-resp
12266:3 (512) 0xae040000
helios.132 > jssmag.209.165 : atp-resp
12266:5 (512) 0xae040000
jssmag.209.165 > helios.132 : atp-rel
12266<0-7> 0xae030001
jssmag.209.133 > helios.132 : atp-req*
12267<0-7> 0xae030002

Jssmag.209 initie l'ID de transaction 12266 avec l'hôte helios en demandant

jusqu'à 8 paquets (le `<0-7>'). Le nombre hexadécimal à la fin de la ligne est
la valeur du champ « userdata » dans la requête.

Helios répond avec 8 paquets de 512 octets. Le `:digit' suivant l'identifiant de

la transaction donne le numéro de séquence du paquet dans la transaction et
le nombre entre parenthèses est la quantité de données dans le paquet, à
l'exclusion de l'en-tête ATP. Le « * » sur le paquet 7 indique que le bit EOM a
été activé.

Jssmag.209 demande alors que les paquets 3 et 5 soient retransmis. Helios

les renvoie puis jssmag.209 libère la transaction. Enfin, jssmag.209 initie la
requête suivante. Le « * » sur la requête indique que XO (« exactement une
fois ») n'a pas été défini.

RÉTROCOMPATIBILITÉ
Les noms d'indicateur TCP tcp-ece et tcp-cwr sont devenus disponibles lors
de la liaison avec libpcap 1.9.0 ou version ultérieure.
VOIR ÉGALEMENT
stty (1), pcap (3PCAP), bpf (4), nit (4P), pcap-savefile (5) , pcap-filter (7) , pca
p-tstamp (7)
https://www.iana.org/assignments/media-types/application/vnd.tcpdump.pcap

AUTEURS
Les auteurs originaux sont :

Van Jacobson, Craig Leres et Steven McCanne, tous du Lawrence Berkeley

National Laboratory, Université de Californie, Berkeley, Californie.

Il est actuellement maintenu par The Tcpdump Group.

La version actuelle est disponible via HTTPS :

https://www.tcpdump.org/

La distribution originale est disponible via FTP anonyme :

ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z

La prise en charge IPv6/IPsec est ajoutée par le projet WIDE/KAME. Ce

programme utilise OpenSSL/LibreSSL, sous des configurations spécifiques.

INSECTES
Pour signaler un problème de sécurité, veuillez envoyer un e-mail à
security@tcpdump.org.
Pour signaler des bugs et autres problèmes, contribuer à des correctifs,
demander une fonctionnalité, fournir des commentaires génériques, etc.
veuillez consulter le fichier CONTRIBUTING.md à la racine de l'arborescence
des sources de tcpdump.

NIT ne vous permet pas de surveiller votre propre trafic sortant, BPF le
fera. Nous vous recommandons d'utiliser ce dernier.

Il faudrait tenter de réassembler les fragments IP ou, au moins, de calculer la

bonne longueur pour le protocole de niveau supérieur.

Les requêtes inverses du serveur de noms ne sont pas vidées correctement :

la section de questions (vide) est imprimée plutôt que la requête réelle dans la
section de réponses. Certains pensent que les requêtes inverses sont elles-
mêmes un bug et préfèrent corriger le programme qui les génère plutôt
que tcpdump .

Une trace de paquet qui traverse un changement d’heure d’été donnera des
horodatages faussés (le changement d’heure est ignoré).

Les expressions de filtre sur des champs autres que ceux des en-têtes Token
Ring ne géreront pas correctement les paquets Token Ring routés par la
source.

Les expressions de filtre sur des champs autres que ceux des en-têtes 802.11
ne géreront pas correctement les paquets de données 802.11 avec les
paramètres To DS et From DS définis.

Le proto ip6 devrait poursuivre la chaîne d'en-tête, mais ce n'est pas le cas
pour le moment. La protochain ip6 est fournie pour ce comportement.

L'expression arithmétique sur les en-têtes de couche de transport,

comme tcp[0] , ne fonctionne pas sur les paquets IPv6. Il ne regarde que les
paquets IPv4.

INDICE
NOM
SYNOPSIS
DESCRIPTION
OPTIONS
EXEMPLES
FORMAT DE SORTIE
Horodatages
Interface
En-têtes de niveau de lien
Paquets ARP/RARP
Paquets IPv4
Paquets TCP
Combinaisons particulières d'indicateurs TCP (SYN-ACK, URG-ACK, etc.)
Paquets UDP
Requêtes de serveur de noms TCP ou UDP
Réponses du serveur de noms TCP ou UDP
Décodage SMB/CIFS
Requêtes et réponses NFS
Demandes et réponses AFS
KIP AppleTalk (DDP en UDP)
Paquets NBP
Paquets ATP
RÉTROCOMPATIBILITÉ
VOIR ÉGALEMENT
AUTEURS
INSECTES
COLOPHON
Cette page de manuel HTML a été générée à 11:10:01 GMT, le 22 octobre
2023, à partir d'une page de manuel source dans les référentiels git « The
Tcpdump Group » à l'aide de man2html et d'autres outils.