You're probably supplying the wrong value as the width ...
I probably don't understand the documentation.
> I think that we have different things in mind. It is not obviousness, it is
> meaning that I am interested in. A single letter is sufficiently meaningful
> or mnemonic (but I agree that it may not be obvious). I believe that
> most people using a packet analyser are, or intend to become,
> familiar with those fields that are important to them or their work.
That doesn't necessarily mean they'll associate the letter you've chosen
with the field (especially if more than one field begins with the same
letter). I *do* consider obviousness important, and would prefer not to
*have* to learn what the one-letter mnemonics mean before I can
understand a dissection.
That is a perfectly good point & makes you free to give less weight
to my idea. My perspective is that I know the protocol (or I am prepared
to learn it) and want a tool to give me the bits in a reasonable format. I am
one of the 'they' in you paragraph.
Your perspective is that you understand and wish to explore networking,
but you are not intimate with each and every protocol. You require
all dissections to be somewhat stereotyped and easily 'speed-read'.
You see ethereal a tool to turn a harsh spotlight on each and every
packet to 'reduce' it to its bare bones as an X-ray does to the human
frame.
Obviously if you feel that you are right I will go along with your
methods.
> Your second point is why I would make the textual description present
> but optional.
"Optional" in what sense?
If the [+] is turned off, it cannot be seen.
> I cannot altogether agree with your third point, it is the protocol's
> documentation not ethereal's that needs digging out.
The protocol's documentation won't necessarily indicate which letters
the author of the dissector has chosen for the bits in question. One
might eventually learn that, but I don't think one should be *obliged*
to learn it in order to use a protocol analyzer.
You are right. That is the same point you made above & I agreed with
it there.
> It is the fact that flags should
> be presented in smallest 'encoding' consistent with retaining all the
> information. Think of the little displays that you can get to show modem
> status on your screen if you don't have an external modem.
I might still want to have a way of getting the display to indicate what
"CD" or "TxD" means. Small encodings sometimes achieve their brevity by
obliging the user to have wired into their brains a dictionary for
abbreviations.
Again, you are right, and I plead the same as the immediately preceding
point. A good use of [+] and a sub-tree should do the trick.
I consider the following:
Flags: 0x0012 (SYN, ACK)
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
to display a collection of 6 one-bit Boolean bitfields, so I *do*
consider you to be dealing with bitfields.
You know the code better than I ever will. At the moment I feel
that flags or booleans with are inherently on or off can with
advantage be treated as a special case wheres bitfields
are more like tiny its and should be treated as UINT or numeric.
Maybe I will change my mind when I know more.
This could be considered a deficiency in the way that the protocol tree
code handles Boolean bitfields - other dissectors, and parts of Ethereal
rolling their display of bitfields "by hand", might display it as
.... ...0 = Not a retransmission
or
.... ...1 = Retransmission
Thanks for that, I will keep it mind.
I am likely to be away for about a week, but expect something in due course.
Ben.
--
Leedsnet - The information resource for Leeds and the West Riding
< URL:http://www.leedsnet.com/mobile/ >
