Hi guys!
I'm stuck with a problem with Wireshark.
Background: I got a file filled with Raw Ip Packets captured by a third party device. In order to make it readable by Wireshark i wrote a little C program converting the raw ip format into a wireshark readable one. It worked well for 99% of the cases. FYI this is the code:
#include < stdio.h >
#include < stdlib.h >
typedef struct pcap_hdr_s {
uint32_t magic_number; /* magic number */
uint16_t version_major; /* major version number */
uint16_t version_minor; /* minor version number */
int32_t thiszone; /* GMT to local correction */
uint32_t sigfigs; /* accuracy of timestamps */
uint32_t snaplen; /* max length of captured packets, in octets */
uint32_t network; /* data link type */
} pcap_hdr_t;
typedef struct pcaprec_hdr_s {
uint32_t ts_sec; /* timestamp seconds */
uint32_t ts_usec; /* timestamp microseconds */
uint32_t incl_len; /* number of octets of packet saved in file */
uint32_t orig_len; /* actual length of packet */
} pcaprec_hdr_t;
int main(int argc, char *argv[])
{
unsigned char ipbuf[65537];
uint32_t length;
char minibuf[8];
uint32_t longvar;
uint32_t shortvar;
char outfile[8192];
pcap_hdr_t hdr;
pcaprec_hdr_t pkt;
if (argc < 2)
{
printf("Usage: a.out [rawip filename]\n");
exit(1);
}
sprintf(outfile, "%s.pcap", argv[1]);
FILE *fp = fopen(argv[1], "r");
FILE *ofp = fopen(outfile, "w+");
/**** DUMP HEADER ****/
hdr.magic_number = 0xa1b2c3d4;
hdr.version_major = 2;
hdr.version_minor = 4;
hdr.thiszone = 0;
hdr.sigfigs = 0;
hdr.snaplen = 65535;
hdr.network = 228; // means raw ip4
fwrite(&hdr, 1, sizeof(pcap_hdr_t), ofp);
while ((fread(ipbuf, 1, 4, fp) > 0) && (!(feof(fp))))
{
length = (uint32_t) (ipbuf[2] * 256 + ipbuf[3]);
if (fread(&ipbuf[4], 1, length - 4, fp) < 1)
break;
// build and dump packet header
pkt.ts_sec = 0;
pkt.ts_usec++;
pkt.incl_len = (uint32_t) length;
pkt.orig_len = (uint32_t) length;
fwrite(&pkt, 1, sizeof(pcaprec_hdr_t), ofp);
// finally, dump data
fwrite(ipbuf, 1, length, ofp);
}
fclose(fp);
fclose(ofp);
exit(0);
}
My problem is that lately, i’ve obtained a pcap file that partically can’t rebuild part of the TCP stream. The latter contains HTTP packets, POST as request and 200 OK as response.
The POST part is not reassembled but the 200 OK is.
“Follow TCP stream” command seems like fully rebuild the stream. That’s weird.
How can I get any information about the errors during the TCP reassembly? Is it possible that is my conversion program the culprit?
Thank you in advance
UPDATE
I came up that the problem is about the order the packets are written into the ipraw file. Infact it DOESN’T MATCH with the order the packets are captured from the device.
Despite the wrong order, if I select “Follow TCP stream” the correct conversation is rebuilt (so, i can tell wireshark CAN rebuild the TCP flow correctly), but into the main wireshark window, it can’t recognize it contains an HTTP (MMS) stream and i can’t filter it.
I wrote a little program that manually switch the out-of-order packets and wireshark recognize 100% the HTTP stream.
There’s a way to tell wireshark to try to always follow the TCP streams and ignore the order of the packet written to pcap file?
asked 21 Jan ‘13, 07:08
Davide Berra
11●1●1●3
accept rate: 0%
It might help if you post the resulting pcap file somewhere, e.g. Cloudshark and add a link back to it here by editing your question. Only post the capture if the contents can be made public.
Unfortunally it contains reserved data but i can make print screen with the sensible data obfuscated if you guide me on what you want to see.
Debugging stuff via print screen output isn’t usually very efficient, and more so for reassembly as you need to see all the preceding packets. You can try to add screenshots to see if someone can help.
Just a question… the timestamp i arbitrarily set to every packet i dump, can lead to error during the TCP reassembly? Or wireshark uses just TCP sequences to rebuild the stream?
The HTTP dissector uses a TCP reassembly function by continuously asking for more data from the stream until it gets all that’s required, I don’t think timestamp is relevant here.
Can you confirm you have enabled reassembly for all the parts in the http protocol preferences?
I forgot to mention that is HTTP POST of an MMS message. Could it act different compared to HTTP dissector? Anyway, i confirm that i have enabled reassembly for all the parts.
The HTTP dissector reassembles the content of the post, de-chunks and decompresses it as required, then hands the data off to sub-dissectors if one can be found to handle the specific data type.