Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


reassembleing a datagram from packets

This topic is 5894 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

This doesn''t have anything to do with game programming but I am writing a packet sniffer and want to be able to recombine a datagram and write it to a file. I am using WinPCap to actually capture the packets. I can use the acknowledgement number in the TCP header to find all the packets that belong to a datagram, but sometimes they arrive out of order. how can I tell what order they should be in? Jason Mickela ICQ : 873518 Excuse my speling. The V-Town Have-Nots

Share this post

Link to post
Share on other sites
Guest Anonymous Poster
I''ll tell you the best way to do it but you will need to redo a lot of your code. When my team and I built a host based intrusion detection product we had the same need (for obvious reasons). The initial designers had an implementation that used pcap libraries and did all their own reassembly. We re-wrote all of that (it wasn''t real good anyway) with a device driver. The driver used a multi-tap system to tap into the TCP\IP stack at different levels, thus the stack dealt with all of the reassembly issues. Then you just need to build a shared memory manager and some queues to move the data from kernel space into user space.

There are a few drawbacks to this method but it improved efficiency a great deal and the speed was increased about 2000%. The original implementation was on Solaris 2.6, you should be able to do this on Windows as well.

As for your question - do you need to do:

TCP stream reassembly (put the streams back)
TCP packet reordering (reorder the seq, subset of above)
TCP state tracking (also subset of stream reassembly)
Also, IP fragmentation can occur in your streams and to deal with that you need to look at the IP packet - it will tell you that the datagram/TCP packet is fragmented and how to reassemble it.

Most of this is discussed in TCP\IP vol I. If you are going to write a sniffer of any sort I would get a copy. Another option would be to look for a tcpdump utility for windows ( I know they are out there ) or just look at the code in the linux dist for said utility.

GL -

Share this post

Link to post
Share on other sites
I need to do packet re-ordering. I don''t want to write my own drivers (or stack). I havn''t noticed any missed packets, but they are out of order about 50% of the time. How can I use the TCP or IP headers to put them back into order?

Jason Mickela
ICQ : 873518
Excuse my speling.

The V-Town Have-Nots

Share this post

Link to post
Share on other sites
In the IP-header, there are 16 bits (bit 48-63) of fragment information. The information consists of, as read from bit 48, a reserved flag (should be zero), a don''t fragment bit (DF), a more fragments bit (MF), and a fragment offset (FO).

DF will be set if no fragmentation is allowed. MF will be set if there are more fragment (that is, if the fragment is not the last one, not if there are more fragments that will arrive on your network interface), and will be cleared if it''s the last fragment. For non-fragmented datagrams, MF is cleared, since there are no more fragments. FO will tell you the offset in the original non-fragmented datagram, counted in number of 8 bytes (the length of a fragment other than the last must therefore be a multiple of 8). To identify which datagram the fragment belong to, look at the identification field, bit 32 to 47. From these fields, you should be able to reassemble a datagram.

Note that the standard says the idetification number should be set by a higher level protocol, such as TCP (even though most implementations let IP set it), so you may need to look at the protocol field also, cause two different datagrams, one from TCP and one from UDP, can have the same identification.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!