Je cherche à pouvoir capturer une sortie tcpdump rotative qui capture 30 minutes de données, dans 48 fichiers, de manière cyclique.
La page de manuel implique que cela devrait être possible, mais mes tests ne semblent pas produire le résultat que je recherche:
-W
Utilisé conjointement avec l'
-C
option, cela limitera le nombre de fichiers créés au nombre spécifié et commencera à remplacer les fichiers depuis le début, créant ainsi un tampon «rotatif». De plus, il nommera les fichiers avec suffisamment de 0 au début pour prendre en charge le nombre maximal de fichiers, ce qui leur permettra de trier correctement.Utilisé conjointement avec l'
-G
option, cela limitera le nombre de fichiers de vidage tournés qui seront créés, en quittant avec le statut 0 lorsque vous atteindrez la limite. S'il est également utilisé avec-C
, le comportement entraînera des fichiers cycliques par tranche de temps.
J'exécute cela sur les clients OS X 10.9.5 / 10.10.3. Voici la commande de test; il sort juste après le 3ème fichier:
tcpdump -i en0 -w /var/tmp/trace-%Y-%M-%d_%H.%M.%S.pcap -W 3 -G 3 -C -K -n
Réponses:
C'est parce que vous avez écrit
-W 3
au lieu de-W 48
. Il y a cependant d'autres erreurs dans votre commande.L'option
-G
signifie:Depuis que vous avez écrit
-G 3
, vous effectuerez une rotation toutes les 3 secondes, pendant que vous déclarerezEn outre, le schéma de dénomination est incorrect: à partir de ce qui précède,
Il est donc inutile de spécifier le format d'heure pour le nom.
De plus, l'
-C
option n'a pas d'argument, alors que, selon la page de manuel , elle devrait:La page de manuel indique:
Vous devez donc spécifier
-C 100
afin de produire des fichiers de 100 Mo.Au final, votre commande devrait être:
Cela fera tourner les fichiers (des noms trace1, trace2, ...) de manière cyclique, avec une période de 48, soit toutes les 1800 secondes (= 30 minutes) ou toutes les 100 Mo, selon la première éventualité.
la source
If no time format is specified, each new file will overwrite the previous.
Extension de la réponse de flabdablet (changement
-G 1800
en-G 300
- rotation toutes les cinq minutes - uniquement à des fins de test),vous donnera
%m=month
,%d=day of month
,%H=hour of day
,%M=minute of day
,%S=second of day
,%s=millisecond of day
, ce quiTrès utile pour organiser les traces de ces problèmes intermittents embêtants. De plus, si vous n'êtes pas root, vous voudrez peut-être
sudo
et bien sûr en faire un nohup:la source
Il me semble que tout ce dont vous avez besoin est
Le spécificateur de format strftime que -G attend dans le nom de fichier -w ne doit pas représenter une date et une heure complètes. Avec seulement% H et% M dedans, et un temps de rotation d'exactement une demi-heure, toute invocation de tcpdump ne générera que deux valeurs% M différentes à une demi-heure d'intervalle, et les fichiers de trace d'hier seront écrasés à la même heure et les nombres de minutes roulent à nouveau.
la source
Après quelques expérimentations, je n'ai pas pu faire fonctionner la réponse @MariusMatutiae comme prévu. Si l'heure est devenue le facteur limitant et sans l'ajout du format d'heure au nom de fichier, le fichier pcap actuel est simplement écrasé.
Par exemple, essayez:
Tout ce que vous vous retrouvez est
trace.pcap0
d'écrire encore et encore.Comme il l'a suggéré dans le commentaire, si vous ajoutez la mise en forme de l'heure au nom de fichier, vous vous retrouvez simplement avec chaque liste croissante de fichiers.
Par conséquent, j'ai dû m'en tenir à des fichiers simples de taille limitée:
la source
Oui, cela ne semble pas fonctionner comme le dit la réponse de MariusMatutiae .
Il me semble qu'il pourrait capturer autant de
-C 100
fichiers Mo que possible sur une période de 30 minutes, car ilhttpdebug.pcap03
a l'horodatage le plus précoce et il est beaucoup plus petit que 100 Mo, il semble donc qu'il ait été coupé à 30 minutes. Une fois qu'il atteint 30 minutes, il semble revenir en arrièrehttpdebug.pcap00
et incrémenter le nombre lorsqu'il atteint 100 Mo. Cela signifie que si vous avez beaucoup de demandes en 30 minutes, vous obtenez des numéros httpdebug.pcapXX très élevés. Si vous n'atteignez plus autant de demandes dans une période, ces chiffres élevés de httpdebug.pcapXX ne seront jamais écrasés.Donc, je pense que les fichiers cycliques par tranche de temps signifient que la tranche de temps est
-G 1800
et qu'elle cyclera chaque-G 1800
et incrémentera chaque-C 100
.Je ne sais pas si
-W 48
cela l'affecte, mais peut-être que si vous y arrivezhttpdebug.pcap47
(le décompte commence à 0, cela arrêtera de capturer les paquets.Un peu récemment, un problème GitHub a été ouvert concernant la formulation confuse. Ils n'ont pas modifié l'implémentation, mais ils ont essayé de rendre la documentation un peu plus claire.
Les modifications proposées ont été fusionnées le 28 janvier 2019 .
À compter d'aujourd'hui, le 17 mars 2019, voici la documentation actuelle:
-C
:-G
:-W
:Je pense toujours que c'est un peu déroutant, mais je suppose que la différence par rapport à ma conclusion ci-dessus, c'est qu'il dit que
-W
lorsqu'il est utilisé avec-C -G
n'affecte rien d'autre que le nom du fichier.En général,
-W
est utilisé pour limiter le nombre de fichiers. Alors ne l'utilisez pas si vous voulez capturer indéfiniment.la source