Matt, you are setting 1 as the file link type. 1 is DLT_EN10MB or "Ethernet (10Mb)", which means the datalink length is 14 bytes. This implies that, per packet, tcpdump will read the pcap header (8-byte timestamp, 4-byte caplen, 4-byte length), *then* interpret the next 14 bytes as the datalink header, and only then start reading the IP header. If tcpdump finds something weird in either the datalink or the IP header, it may think the file is corrupted. In your case, this is probably happens with both.
You have two alternatives: first, create a false Ethernet header. Check the "Ethernet II" format at: http://www.connectotel.com/netware/frame.txt It doesn't mind too much what you put in the addresses, as long as the frame type is 0x0800 (IP). The second alternative is to use the raw IP format. You have to set p_head.linktype to DLT_RAW, and then start writing the IP header. Hope this helps. -Chema Matt Goward wrote: > > 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 - 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
