重新组合碎片UDP数据包

Question

I have a pcap of various types of traffic over 802.11 (wifi) over udf. The udp (or more precisely IP) fragments the wifi packets due to the MTU. I am currently using SharpPcap to read in and try and access the wifi traffic and am running into the issue of having to manually reassemble the udp packets.

I see two options, and I want to check if they are possible, the best solutions or if there is something I'm overlooking. Ultimately I will be accessing a live feed (same format, wifi over UDP) streamed to me over UDP (the one preciously mentioned), but for testing purposes I have to play with pcaps.

I can either manually load the pcap file, reassemble it by fragment offset and packet id, having a state machine keeping track of all packets. Or I can try and avoid reassembly, (I figure the socket should do it for me) load the pcap file, output to a raw socket on localhost, and listen to a UDP socket on the localhost. I am avoiding the first until really necessary (is it?) and the second seems like it should work but doesn't. I have all that set up, but the packets still get send and received one by one, as byte arrays - and fragmented.

Could this be because the IP layer still contains the original captured IP dest address and port (which is different)? I tried changing these prior to sending, although I didn't change the checksum, and it still came through fragmented.

Answer 1

Ran into your old question searching for a solution to my own problem defragmenting.

The way I understand it - since you're doing packet capture / pcap reading, you have to defragment the IP packets yourself. If you were an actual application communicating on the network, the IP stack of your OS would do this for you, and you could read the data as is. But packet capture happens before this reassembly. What you're seeing is packets as they travel on the wire (or in the air in your case).

Defragmenting is in theory relatively easy - the IP packets that have the same ID, source/destination IP address, and protocol type, belong together. The first packet will have a fragmentation offset of 0 and the "More fragments" field set to 1. The next packets (if any) will have "More fragments" set to 1, and a nonzero offset. The final packet will have a nonzero offset and no "More fragments" set.

Get rid of duplicates somehow, order them by offset. The payload of each packet goes into the final buffer at packet.fragmentationOffset*8. It is also trivial to calculate the final packet size using this information.

A more thorough explanation can be found here: http://en.wikipedia.org/wiki/IPv4#Reassembly

I know you have probably moved on a long time ago, but perhaps this could help someone else searching for the same information.