Ethereal-dev: Re: [Ethereal-dev] SMB NetServerEnum2 RAP response incorrect bytes

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Aaron Carlson <[email protected]>
Date: Tue, 13 Jul 2004 10:37:34 -0700
On Tue, Jul 06, 2004 at 10:45:36 -0700, Guy Harris wrote:
>> Ethereal (v 0.10.3 and 0.10.4) is highlighting the incorrect bytes for the
>> 'Server Type' field within the Server_Info_1 structures in the
>> NetServerEnum2 RAP response.  I just checked and it is also highlighting
>> incorrect bytes for browser protocol decodes (host/master announcements).
>>
>> In the "Packet Details" pane the 'Server Type' field shows the correct
>> values, but in the "Packet Bytes" pane the bytes for the 'Server Comment'
>> field are highlighted.  The 'Server Comment' field is a pointer, and the
>> actual 4-byte pointer value is highlighted, not the string it points to).
>
>What makes the pointer value any more intrinsically "incorrect" than the
>string it points to?
>
>If thee's a "correct" answer, it's "highlight the pointer *and* the
>bytes", but we don't currently have any mechanism for specifying that a
>field consists of two discontiguous regions of the packet.  I've thought
>on occastion that it'd be useful to have such a mechanism for purposes
>such as this.


Sorry I should have been more explicit.  The problem isn't that it highlights the pointer to the string.  The problem is it highlights the pointer to the string of a *different field*.  The field I clicked on isn't even a pointer.  When you click on 'Server Type' field (NOT on the 'Server Comment' field), it highlights the *comment* field's pointer.  The comment field correctly highlights the actual comment (not the pointer) so that may have something to do with why the 'Server Type' field (the field immediately preceding the comment pointer) is incorrectly highlighted.

Whether or not a field in the RAP heap represented by a pointer should be highlighted as the raw pointer or the data in the heap is another issue altogether :)

-Aaron