On Sun, Apr 15, 2001 at 12:02:27PM -0400, Ed Warnicke wrote:
> I disagree. One of the really useful purposes I see for ethereal is
> pedagogical. Ethereal is a useful for allowing people to see the
> structure of protocols that they had only read about in RFCs previously.
> Showing people the bytes things come from is a part of this.
Perhaps, although the question then is whether regions of the packet
pointed to by pointers in compressed DNS names are part of the name
field in question, or merely referred to *by* the name field.
However:
> Having get_dns_name() return a tvbuff, and using that tvbuff so as to
> have the bytes in the data pane highlighed when you select the appropriate
> field in the dissection pane does a lot to facilitate this.
...using tvbuffs for that is not the *only* way to do that, and I'm
unconvinced that it's the *right* way to do that.
Tvbuffs are, I think, overkill for this situation - they were created
as a mechanism for "wrapping" a packet up in such a way that data can be
extracted from it with bounds checks; they weren't intende for use to
wrap individual fields.
Whilst it might be possible to wrap fields up in them, I consider that
overkill for this situation - "get_dns_name()" should continue to return
the name string in any case, so it's not as if you'll fetch the name
from the tvbuff (in order to figure out what to put into the tvbuff,
"get_dns_name()" will have to fetch the name anyway, and fetching the
name from the tvbuff requires as much work - if not *more* work, given
that the offsets in pointers are offsets within the DNS request, not
within that tvbuff).
In addition, I suspect that the code to support discontiguous fields in
that fashion might not exist in the code to handle the hex dump pane,
and might have to be written anyway.
I think a better solution would be to simply accumulate a list of
offset/length pairs in "get_dns_name()", and have a way of attaching
such a list to a protocol tree entry; without such a list, the
offset/length used when adding the entry to the protocol tree would be
used, and the list would replace (or supplement, if it didn't contain
the original offset) the offset/length when the protocol tree entry was
created.
This also raises the question of what entry or entries in the protocol
tree should be selected if you click on bytes in the hex dump pane that
are in more than one name in a DNS packet. If it should select only the
first name field, we'd have to make sure that the code does that; if it
should select all of them (and I'm not at all certain that it should),
we might have to arrange that the protocol tree run in a mode where more
than one entry can be selected.
