> OK, I have fixed the bugs in FTP and will move onto POP. I added a field to > the packet_info structure that tells us the payload length of an IP > datagram and then I check in dissect_tcp for that before calling a dissect > routine. Hmm. At some point, I'm thinking of adding the ability to have more than one "packet", at some layer of the decode, per frame (e.g., multiple ONC RPC calls or replies, or multiple NetBIOS-over-TCP packets, in a single TCP segment), or have more than one frame per "packet" (e.g., a multi-TCP-segment ONC RPC call or reply or NetBIOS-over-TCP packet). For that, we might want "packet_info" to be passed as an argument to dissect routines; a "packet_info" might contain an array of descriptors indicating which parts of which frames the "packet" includes (with the typical case probably being "all of the frame, except for padding and the like"), in which case we could probably have a pointer to a "packet_info" structure replace the pointer to a "frame_data" currently passed.
Powered by MHonArc 2.6.10