Hi,
So I'm using the sample code for the PcapDumper directly from the user guide. It creates a pcap dump file that opens normally in something like Wirehshark, but when I try to open it using jnetpcap API, none of the headers and so forth are recognized normally, it does things like say that Ethernet frames are Token ring frames. This was an issue present in the stable release and is still present in the latest developer build (b0003). Any ideas? Attached is the capture file generated from the PcapDumper routine.
Ab
| Attachment | Size |
|---|---|
| tmp-capture-file.cap | 742.21 KB |
I'll take a look. The file looks normal in wireshark.
It works for me. Make sure that you are closing the dumper handle in order to release the lock on the file, as in the example on line #99:
/*
* Last thing to do is close the dumper and pcap handles
*/
dumper.close(); // Won't be able to delete without explicit close
pcap.close();
If you still can't figure it out, can you attach your code so I can take a closer look?
Ok so it turns out there was nothing wrong with the dump file. What it is was, the dump was generated by a DoS attack, which threw lots of packets who stated their TCP header length was zero. Nonetheless they carried their port information, which wireshark picks up, but since they SAY their header length is zero, jnetpcap seems to drop headers which carry a stated length of zero. Is there a way around this behaviour?
Thanks,
ab
Its going to interpret what the protocol header say the length is. It doesn't drop any existing data in the packet, even if the protocol header is wrong, it just groups all umatched data under a catch-all header Payload. Anything that the last header did not match, is grouped as payload.
The scanner uses the pkthdr_t.caplen as the length of the packet to begin with, no matter what the headers might say. The data is all there. You just have to retrieve it.