I am doing some work with divert sockets on freebsd and as part of my
project i would like to write packets out to a pcap format file, even
though i am not reading them via pcap. So i read the pcap.h file like
a good boy and poke around the net a bit to find:
http://www.ethereal.com/lists/ethereal-dev/199909/msg00124.html
which helps a bit too. So i have my to pcap structs:
struct pcap_file_header p_head;
struct pcap_pkthdr p_packet_head;
I populate my file header struct:
p_head.magic = 0xa1b2c3d4;
p_head.version_major = 2;
p_head.version_minor = 4;
p_head.thiszone = 0;
p_head.sigfigs = 0;
p_head.snaplen = 102400;
p_head.linktype = 1; /* ethernet */
and compair my output to that of tcpdump. so far so good. I get my packet
and do what i need to do with it. I dump it as hex to the screen, and it
really is a valid raw packet.
Then i go to fill my per packet header for pcap:
gettimeofday( &(p_packet_head.ts),NULL );
p_packet_head.caplen = n;
p_packet_head.len = n;
n is the packet size i am getting from my recvfrom call that i am using
to read from my divert socket. I have tested and it is the size of the
packet in bytes, just as the pcap header seems to want it. But none of
this actually works. So i started running tcpdump and my program at the
same time on the same packets. I found the issue, sorta. I lined up the
data in my packets that matched with the same data in the packet from tcp
dump. this is output from hexdump on the dump files i created
c3d4 a1b2 0002 0004 0000 0000 0000 0000 ok so far so good
c3d4 a1b2 0002 0004 0000 0000 0000 0000
0060 0000 0001 0000 8534 3d8f f55b 000c
0060 0000 0001 0000 8534 3d8f f55b 000c
004a 0000 004a 0000 3000 071b 69a4 e000 hrm i seem to be missing 14 bytes
003c 0000 003c 0000 my packet size numbers are off by
the same 14 bites :/
7f2b 009e 0008 0045 3c00 54d2 0040 0636
0045 3c00 54d2 0040 0636 but beyond that the actual packets
` are exactly the same
fcce 3b94 032f c742 659d 1210 a519 af26
fcce 3b94 032f c742 659d 1210 a519 af26
0752 0000 0000 02a0 ffff 5ac6 0000 0402
0752 0000 0000 02a0 ffff 5ac6 0000 0402
b405 0301 0103 0101 0a08 531b 8123 0000
b405 0301 0103 0101 0a08 531b 8123 0000
0000
0000
Ok so this chunk of data that i am missing makes it impossible to read
my data with tcpdump. But I started looking at what these 16 bytes could
be. Only to find they dont seem to change. If i make a little array:
u_int16_t filler[7];
filler[0] = 12288;
filler[1] = 1819;
filler[2] = 27044;
filler[3] = 57344;
filler[4] = 32555;
filler[5] = 158;
filler[6] = 8;
And print this in my file after my packet header data and before the actual
packet, and add 14 to my packet lengths:
p_packet_head.caplen = (n + 14);
p_packet_head.len = (n + 14);
Then the file becomes valid and exatly the same as what tcpdump is writing.
But tcp dump does not seem to write this data anywhere, i have no idea
where it is coming from. I suspect doing things this was is not going
to be the best way to ensure things will work as pcap gets updated over
time either.
I was hoping someone could tell me what this data is, where it is coming
from when tcpdump writes its files, why i need it etc. This is a really
ugly way to have to write my files out.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
