[Openpacket-devel] Fwd: Pcap file checksum calculation
Brought to you by:
crazy_j,
taosecurity
Menu
▾
▴
[Openpacket-devel] Fwd: Pcap file checksum calculation
|
From: Tim F. <fu...@cc...> - 2006-08-03 04:06:58
|
---------- Forwarded message ---------- From: Tim Furlong <tim...@gm...> Date: Aug 3, 2006 12:05 AM Subject: Re: [Openpacket-devel] Pcap file checksum calculation To: David Belle-Isle <ml...@im...> Cc: ope...@li... You may also want to take a look at libnetdude ( http://netdude.sourceforge.net), particularly with the traceset and conntrack plugins, before you get too deep into writing your parser. There's also libqcap (http://www.sourceforge.net/projects/qcap) developed by one of my colleagues here at Carleton, which implements ip fragment handling and tcp tracking, and he's building a protocol parsing grammar on top of it (like ABNF, but able to handle non-ABNF things often found in protocols like length fields). The main drawback is that it's only really set up to handle IP over Ethernet, though I'll be adding support for Cisco HDLC tomorrow or early next week, and it's easy to add any datalink layer with a constant header length; just change the offset of the IP header. :P As for the question of flexibility, there'd undoubtedly be things that these libraries do that you'll look at and say, "I wouldn't have done it that way", but they may be worth a look to see if they'd give you the power you need for your purposes without constraining you too badly. -Tim On 8/2/06, Tim Furlong <fu...@cc...> wrote: > > > Which checksum are you looking at? I don't think PCAP files have checksums > of their own, so I'm assuming you're talking about the IP header checksum > and/or the TCP checksum. > > IP (RFC791, section 3.1, http://rfc.net/rfc791.html) - > Header Checksum: 16 bits > > A checksum on the header only. Since some header fields change > (e.g., time to live), this is recomputed and verified at each point > that the internet header is processed. > > The checksum algorithm is: > > The checksum field is the 16 bit one's complement of the one's > complement sum of all 16 bit words in the header. For purposes of > computing the checksum, the value of the checksum field is zero. > > This is a simple to compute checksum and experimental evidence > indicates it is adequate, but it is provisional and may be replaced > by a CRC procedure, depending on further experience. > > So to recap, you take the IP header, zero out the checksum, take a zeroed > out 16-bit register, and XOR it with each 16-bit chunk of the header. > > TCP checksum (RFC793, section 3.1, http://rfc.net/rfc793.html) - > The checksum field is the 16 bit one's complement of the one's > complement sum of all 16 bit words in the header and text. If a > segment contains an odd number of header and text octets to be > checksummed, the last octet is padded on the right with zeros to > form a 16 bit word for checksum purposes. The pad is not > transmitted as part of the segment. While computing the checksum, > the checksum field itself is replaced with zeros. > > The checksum also covers a 96 bit pseudo header conceptually > prefixed to the TCP header. This pseudo header contains the Source > Address, the Destination Address, the Protocol, and TCP length. > This gives the TCP protection against misrouted segments. This > information is carried in the Internet Protocol and is transferred > across the TCP/Network interface in the arguments or results of > calls by the TCP on the IP. > > +--------+--------+--------+--------+ > | Source Address | > +--------+--------+--------+--------+ > | Destination Address | > +--------+--------+--------+--------+ > | zero | PTCL | TCP Length | > +--------+--------+--------+--------+ > > The TCP Length is the TCP header length plus the data length in > octets (this is not an explicitly transmitted quantity, but is > computed), and it does not count the 12 octets of the pseudo > header. > > A bit more complex: you construct and prepend a 12-octet pseudoheader as > shown in the diagram using fields from the IP header before you start, and > you again zero out the checksum before you compute it. You also pad out the > payload to an even number of octets (so that you only have full 16-bit > chunks). Note that the checksum covers the TCP payload as well, so the > total number of octets checksummed should be "total length from IP header" - > ( "header length from IP header" x 4 ) + 12 for the pseudo header. The x4 > is because the header length from the IP header is given in 32-bit words, > not octets. Once you've constructed that, you again just iterate over each > 16-bit chunk and XOR it with your register. Alternately, I think you could > leave the old checksum in and just test that your new checksum is 0. > > Hope this helps, > -Tim > > > On 8/2/06, David Belle-Isle < ml...@im...> wrote: > > > > Hi everyone, > > > > I wonder if everyone could help me find how the checksum is calculated > > in > > a pcap file ?? > > > > Let me know if you have any idea, > > > > Thanks, > > > > David > > > > > > Also note that this friday I'll open up the server for people to test > > the > > version of openpacket I've developped so far! I'll send another email to > > give the details. > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys -- and earn cash > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Openpacket-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openpacket-devel > > > > > > -- > Tim Furlong > tim...@gm... > -- Tim Furlong tim...@gm... -- Tim Furlong tim...@gm... |
