reassembleing a datagram from packets
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
"The paths of glory lead but to the grave." - Thomas GrayMy Stupid BlogMy Online Photo Gallery
May 30, 2002 06:51 PM
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 -
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 -
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
Jason Mickela
ICQ : 873518
Excuse my speling.
The V-Town Have-Nots
"The paths of glory lead but to the grave." - Thomas GrayMy Stupid BlogMy Online Photo Gallery
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement