matt, most likely you are missing to write the l2 header i.e. for ethernet
6 bytes of dest mac address 6 bytes of source mac address and 2 bytes of ethertype (0x800) ----- 14 bytes /hannes On Wed, Sep 25, 2002 at 04:28:47PM -0400, 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
