Assuming you're writing the packets yourself, make sure to match the byte ordering in the global header magic number and the length fields in the packet header.
This is my Global header :
typedef struct pcap_hdr_s {
uint32_t magic_number;
uint16_t version_major;
uint16_t version_minor;
uint16_t thiszone;
uint32_t sigfigs;
uint32_t snaplen;
uint32_t network;
} ;
pcap_hdr_s pcap_hdr_tr;
pcap_hdr_tr.magic_number = 0xd4c3b2a1;
pcap_hdr_tr.version_major = 2;
pcap_hdr_tr.version_minor = 4;
pcap_hdr_tr.thiszone = 0;
pcap_hdr_tr.sigfigs = 0;
pcap_hdr_tr.snaplen = 65535;
pcap_hdr_tr.network = 1;
And this is my packet header:
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 */
} ;
char RxPuffer[256] = {0}; // RxPuffer will store the incoming serial data
pcaprec_hdr_s pcaprec_hdr_t;
pcaprec_hdr_t.ts_sec = 0x41B35E88;
pcaprec_hdr_t.ts_usec = 0x0004D80D;
pcaprec_hdr_t.incl_len = strlen(RxPuffer);
pcaprec_hdr_t.orig_len = strlen(RxPuffer);
Could you please clarify if this approach is right?
Thank you :)
pcap_hdr_tr.magic_number = 0xd4c3b2a1;
As per the pcap-savefile man page, the magic number is 0xa1b2c3d4, no 0xd4c3b2a1.
If you write out a magic number with the value 0xa1b2c3d4, you are indicating that the file's byte order is the same as the byte order of the machine writing the file, so all the other multi-byte values in the file header and in the packet headers can be written out in the byte order of the machine writing the file.
If you write out a magic number with the value 0xd4c3b2a1, you are indicating that the file's byte order is the opposite byte order from the byte order of the machine writing the file, so all the other multi-byte values in the file header and the packet headers must be written out in the opposite byte order of the host that's writing the file, so you'd have to byte-swap ...
Asked: 2019-06-05 11:54:53 +0000
Seen: 1,069 times
Last updated: Apr 25 '20
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
Either 1) you really do have packets that large or 2) somehow the file you're trying to read got damaged, and there may be other problems with the file, even if you change the packet headers. How was that file produced?
We are sending the global and packet headers to the pipe directly without writing to a file. The error pops up while writing the packet header.
What program is writing the headers to the pipe? That program may be buggy. What happens if you run the program, send its output to a file rather than a pipe, and then try to read the file with Wireshark?
I tried writing to file but when I tried to open the pcap file, it says "The file "test.pcap" isn't a capture file in a format Wireshark understands."
I have attached my entire code above. Could you please have a look at it and suggest changes, if any?
I've rolled back your massive change of question. This is not the place to dump source code. Use other public accessible sites for this, e.g., GitLab, GitHub, pastbin or similar.
hey i am getting same error. Did you find any solution for it