inspiré par @sch voici une version bash:
file=cap.pcap
$tshark -Tfields -e tcp.stream \
-e frame.time_epoch \
-e ip.src \
-e tcp.srcport \
-e ip.dst \
-e tcp.dstport -r $file |
sort -snu |
while read -a f; do
[[ "${f[5]}" ]] || continue # sometimes there is no stream number ex. UDP
fileout=$(echo ${f[0]}__${f[1]}__${f[2]}__${f[3]}__${f[4]}__${f[5]} | tr -d '\r' )
$tshark -r $file -2R "tcp.stream == ${f[0]}" -w "$fileout.pcap"
done
read
le nom du fichier sera comme ça: stream number__time__source IP__port__destination IP__port.pcap
tr -d '\r'
est destiné aux utilisateurs de Windows, car tshark dans Windows affiche CR LF.
Modifier :
cette solution avec tshark est si lente mais sûre. SplitCap est super rapide mais quand il y a une erreur dans un paquet, il se bloque, tandis que tshark ne vous informe que de l'erreur mais continue:
tshark: The file "cap.pcap" appears to have been cut short in the middle of a packet.
et enfin il y a PcapSplitter qui est super rapide aussi mais il a besoin du pilote winpcap, il ne fonctionne pas avec le pilote npcap dans windows.
Mais il existe une solution à SplitCap: en utilisant pcapfix, je peux réparer les paquets corrompus, puis SplitCap ne se bloque plus. et c'est ce que j'utilise maintenant, parce que tshark est si lent à se séparer.
et une solution à PcapSplitter que j'ai faite était d'injecter la DLL winpcap en utilisant n'importe quelle méthode mais alors que nous avons SplitCap pourquoi le faire?