यहां @sch से प्रेरित एक बैश संस्करण है:
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
फ़ाइल नाम इस तरह होगा: stream number__time__source IP__port__destination IP__port.pcap
tr -d '\r'
विंडोज़ उपयोगकर्ताओं के लिए है, क्योंकि विंडोज़ आउटपुट CR LF में tshark।
संपादित करें :
tshark के साथ यह समाधान इतना धीमा है लेकिन निश्चित है। स्प्लिटकैप सुपर फास्ट है लेकिन जब किसी पैकेट में कोई त्रुटि होती है तो यह क्रैश हो जाता है, जबकि tshark आपको केवल त्रुटि के बारे में सूचित करता है लेकिन:
tshark: The file "cap.pcap" appears to have been cut short in the middle of a packet.
और अंत में PcapSplitter है जो सुपर फास्ट भी है, लेकिन इसे winpcap ड्राइवर की आवश्यकता है, यह विंडोज़ में npcap ड्राइवर के साथ काम नहीं करता है।
लेकिन स्प्लिटकैप का एक समाधान है: pcapfix का उपयोग करके मैं भ्रष्ट पैकेट को ठीक कर सकता हूं फिर स्प्लिटकैप फिर से क्रैश नहीं होता है। और यह वही है जो मैं अभी उपयोग कर रहा हूं, क्योंकि स्पार्क विभाजन में बहुत धीमा है।
और PcapSplitter के लिए एक समाधान मैं किसी भी विधि का उपयोग करते हुए winpcap dll इंजेक्शन लगा रहा था, लेकिन जब हमारे पास स्प्लिटकैप है तो ऐसा क्यों है?