I checked in some stuff to dissect HTTP (ports 80 and 8080); it attempts to recognize the lines that appear in HTTP requests and replies, and shows them, with non-printable characters escaped. (The routines to recognize "lines" - which can end with LF, CR-LF, or CR - and to format them with non-printable characters escaped are in "packet.c", and potentially usable by other protocols, e.g. FTP, SMTP, etc..) It reveals a problem with the current way of passing information to the next dissector down, namely that if the dissector at level N knows that its payload ends before the end of the frame (e.g., an Ethernet frame that had to be padded to be at least 60 bytes), it doesn't tell the dissector at level N+1. The ideas I've been thinking about for handling "packets" that take more than one frame (e.g., ONC RPC or NetBIOS-over-TCP requests and replies that fit in more than one IP fragment over UDP or more than one TCP segment), and handling more than one "packet" in a frame (e.g., ONC RPC-over-TCP or NetBIOS-over-TCP requests packed two or more to a TCP segment) would handle this as well, in that the level N decoder would hand the level N+1 decoder a scatter/gather list, if you will, of raw frame data (pointer+length), and possibly a total length as well.
Powered by MHonArc 2.6.10