How to remove from a pcap file a packet which wrongly claims a size > 262144
There is a captured pcap file which appears to be corrupt:
tshark: The file "file.pcap" appears to be damaged or corrupt.
(pcap: File has 20447488-byte packet, bigger than maximum of 262144)
I tried to remove that packet from the trace with:
tshark -r file.pcap -R "ip.len<=65534" -2
but I get the same error:
0.000000 CS0 172.19.0.1 → 228.6.7.8 UDP 47549 46655 114 47549 → 46655 Len=86
...
22622.071058 CS0 172.19.0.1 → 239.255.255.250 SSDP 52107 ssdp 200 M-SEARCH * HTTP/1.1
tshark: The file "file.pcap" appears to be damaged or corrupt.
(pcap: File has 20447488-byte packet, bigger than maximum of 262144)
Is there a workaround to sanitize the trace?
One word: editcap
One sentence: Use a binary transfer mode when sending the file between systems. Ascii transfer will change the CR/LF sequences and is often the cause of these errors.
Two answers: @Jaap: same issue: editcap -s 65534 file.pcap file.pcap.new editcap: The file "file.pcap" appears to be damaged or corrupt. (pcap: File has 20447488-byte packet, bigger than maximum of 262144)
@SYN-bit: this file does not come from a transfer, but was saved directly by ulogd.
what version of ulogd?
2.0.7-1+b2. I'll try to downgrade to see if the old version behaves correctly.
As something corrupted the pcap packet header structure, a display or capture filter won't be able to fix this. The question is why did ulogd write a faulty pcap packet header. Could it be that there were multiple processes writing to the same file?
You can probably load the pcap in Wireshark and then choose "View -> Reload as File Format/Capture", you can then analyze the file structure to see where things went wrong. If you are able to share the file on a public file sharing service, I could have a look at it for you too.
ulogd is triggered by iptables which writes to different types of pcap files when certain conditions are met, such as received invalid packets which are blocked by iptables. This issue does not happen with all the different types of pcap files, only the ones which log all blocked packets. So I'm not convinced that something damaged the pcap packet header structure per se, because I'm able to read the corrupted files up to a point. I'd rather take the error msg to the letter and suppose that the host has indeed received some malformed packets with a length field in the IP or UDP or TCP header reporting that kind of size. In response to "Could it be that there were multiple processes writing to the same file?", since iptables is the only process using ulogd, I would be inclined to answer no, although I'm not ...(more)