See attached patch: defines frame.truncated (FT_BOOLEAN) only if frame is truncated.
Please review and commit. Regards, Olivier | -----Original Message----- | From: Dinesh G Dutt | | Hi all, | | I have a problem related to decoding for which I have a solution. I'd | appreciate it if you could give me feedback on the proposal | and suggest better | alternatives, if possible. | | The basic problem has to do with marking a frame as a | "Malformed Frame". It is | possible with the MDS family of switches & analyzer adapters | to truncate frames | delivered to Ethereal to prevent fewer frame drops and for other | reasons. Separately, in SCSI, an initiator may allocate fewer | bytes than | required to return a response. For example, a normal INQUIRY | response is about | 48 bytes long, but there are lots of cases where hosts | allocate as few as 4 | bytes. In each of these cases, the frame is smaller than | normal. Marking such | frames as "Malformed" seems to cause confusion and affects | viewing experience | according to the feedback that I've received. | | It would be slow and bad for readability to check for every | field if there are | sufficient bytes present. What I was thinking was to instead | add a field to the | packet_info structure called "truncated". If this bit is set, | instead of | marking a frame as malformed when an exception is thrown, we | should mark the | frame as "truncated". | | Any suggestions would be much appreciated. I'll make the | relevant changes and | hope to check it in before the upcoming release, if the | changes are simple | enough. | | Thanks, | | Dinesh | -- | I am not young enough to know everything. - Oscar Wilde | | | _______________________________________________ | Ethereal-dev mailing list | [EMAIL PROTECTED] | http://www.ethereal.com/mailman/listinfo/ethereal-dev |
packet-frame.c.diff
Description: Binary data
