> The best I could get was output like
>
> . = Continuation: No TPIs
> . = Re-transmission Indicator: Re-transmission
You're probably supplying the wrong value as the width - in an
"hf_register_info" structure for a Boolean bitfield such as that, the
values would be something such as
{ &hf_wap_flags_continuation,
{ "Continuation", "wap.flags.continuation", FT_BOOLEAN, 8,
TFS(&flags_continuation_truth), 0x80, "" }},
The "8" specifies the width of the field containing that bitfield, and
is in units of bits; it looks as if you'd specified a width of 1 there,
making Ethereal think the field *containing* the bitfield was also only
one bit wide.
> >Well, I wouldn't assume that somebody looking at a packet trace would
> >necessarily find the one-letter tag obvious in all cases; some protocols
> >might be large enough that some fields might be obvious to most who
> >would look at a packet but others might be infrequently used, in which
> >case a more detailed display would be useful, so somebody doesn't have
> >to dig up the Ethereal documentation to find out what the letter in
> >question means.
>
> 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.
> Your second point is why I would make the textual description present
> but optional.
"Optional" in what sense?
> 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.
> it is not the fullness of the dissection that I am bothered about (I take it
> as read). If a dissection is to be useful at all it has to be full, Or 'nowt
> taken out' as one might say in Yorkshire. 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.
> >I'm not saying *not* to put the summary in; I'm saying that it should
> >not be considered a *substitute* for the bitfield-by-bitfield
> >dissection, but should be considered a *complement* to it - i.e:
>
> Forgive me, I am not dealing with bit fields at all,
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.
> Exactly. One of my reasons for getting 'excited' about this is that 'no
> retransmission' (which sounds like retransmission is forbidden) doesn't
> properly describe that bit. The protocol assumes that packets go across
> slow, lossy media and so it has provision for retransmission. The first
> transmission has the R bit clear and all subsequent ones have the R bit
> set. The recipient can distinguish re-transmissions from packets duplicated
> by the network.
>
> This is easy to symbolise by 0/1 or r/R but a pain to put into words,
> exempli gratia:
>
> .... ...0 = Re-transmission Indicator: First transmission
> .... ...1 = Re-transmission Indicator: Re-transmission
>
> as compared to
>
> .... ...R
>
> (which can be internalised as 'IS a retransmission' or 'IS NOT a
> retransmission'
> very easily).
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
