Wireshark · Ethereal-dev: Re: [ethereal-dev] DIsplay of flags in packet pane

[Ben Fowler <wapdev@xxxxxxxxxxxx>]

My thanks to both you and Gilbert Ramirez for your extraordinarily
clear and well-thought out comments.

At 11:05 PM 4/11/00, Guy Harris wrote:
> > At present, it seems that ethereal regards each and every flag
> > as a single stand alone boolean which is on or off (having appropriate
> > labels in a TRUE/FALSE structure) and displayed left justified.
>
> That's certainly how I think of flag bits within fields (i.e., I
> deliberately wrote the bitfield-dissection code to function the way it
> currently does).

O.K. We are both on the same wavelength

> > This is despite the fact that throughout the code we have comments
> > in the form 'FLAGS field' recognising that flags come in bunches,
> > and programmers are quite used to hardware concepts such as a
> > FLAGS Word, Half-Word or Byte.
>
> ...which is why we also display the entire field in which the various
> bitfields occur.

I'm afraid that I hadn't spotted this.

> We don't think of flag bits as being any different from any other sort
> of bitfield.

My problem was that (1) I need flag bits to be thought of as no different
from any other sort of bitfield, and, (2)  the code did seem to distinguish
between them.

> > For my part, I would like flags to be displayed concisely in their
> > location within a flags field, videlicet:
> >
> >        Header Flags
> >        c... .GTr
> >        .000 1... = PDU Type: Invoke
> >        .... .11. = Trailer flags: Packet re-assembly not supported
> >
> > in which
> >        bit 0 is a flag C = Continuation present, c = continuation absent
> >        bits 1-4 are a bit field holding the type of the packet
> >        bit 5 is the Group Trailer [G/g] flag
> >        bit 6 is the Transmission Trailer [T/t] flag
> >        bit 7 is the Re-transmission indicator [R/r]
>
> This appears to differ from the current scheme only in that
>
>         1) it doesn't display the state of the "c" bit, which I would
>            consider a deficiency - I'd want it to be more like
>
>        Header Flags
>        c... .GTr
>        0... .... = Continuation: absent
>        .000 1... = PDU Type: Invoke
>        .... .11. = Trailer flags: Packet re-assembly not supported
>        .... ...0 = Retransmission: no retransmission

Fair enough. I agree that information needs to be presented in a variety
of appropriate ways, so that our brain's powerful pattern matching
capability gets enough data to get to work on. I could not get ethereal
to produce a line like

>        0... .... = Continuation: absent

which is what I am really after, hence my suggestion of adding something to
ethereal.

>            there is no guarantee that the mere appearance of a "c" or "C"
>            there will necessarily mean anything to the user, so I *REALLY*
>            want to have a full textual description of all fields, including
>            one-bit Boolean fields, not just a concise summary like the
>            "c...  .GTr" line;

That is a fair point, but I was assuming that the 'user' in these cases
was an expert and that C/c was as meaningful as Z/z in the flags
word is to an Intel assembly programmer.

I have a number of female relatives who are school teachers, and have
known from an early age that concise means brief and accurate (or
comprehensive) not just brief. I am putting forward a case for concision
based on my belief that packet capture can produce a very large
quantity of data and presenting it in a physically small or short form
(whilst retaining completeness) could be useful or even essential
in providing our brains with the patterns needed to diagnose problems.

>         2) it doesn't show the value of the entire field (0x0E);

That is a definite drawback. If that is needed in the dissected pane then
I would add it; but I merely arrange to highlight the byte(s) concerned
in the byte window. In my view once I have dissected the field, its
complete value is less necessary to my brain and might even be a
distraction.

>         3) it has the summary line displaying letters for the one-bit
>            Boolean bitfields, which would be OK with me *as long as it
>            didn't replace the detailed description of those fields*.

I haven't fully thought this through. I would have the full textual description
available as a [+] reveal more tree; (you might regard this as training 
wheels),
so in an ideal world it is available as and when needed, but is not a 
distraction.

> > Note that bits 5 and 6 have a special meaning when both are set, that
> > the implementation does not support packet fragmentation/re-assembly
> > at all, and these bits are available for interpretation as bit field.
>
> ...which means it's a special case, unlike, say, the flag bits in a TCP
> flags field, where they're all completely independent.

A situation which is very common in the low level world that packet capture
deals in. My part of the solution is to present the flags concisely and
write out the special cases fully.

> > If I were to submit a patch implementing a type FT_FLAGS_BYTE, would
> > this be accepted. It would be in competition with the existing FT_BOOLEAN
> > type but would not supplant it.
>
> What would that type do?

Meet my needs/scratch my itch. This is OSS ...

You are free to reject it, I would just like to know in advance whether
you have sufficient information from me now to know that my feature
is not attractive.

> The "Header Flags" field (which, the name notwithstanding, is not all
> flags, as the PDU Type field isn't a flag bit) wouldn't in the current
> scheme, be an FT_BOOLEAN field, so presumably the field in its entirety
> wouldn't be FT_FLAGS_BYTE (BYTE would be inappropriate in any case if it
> contained more than 8 bits, unless you're running on, say, a PDP-10
> :-)).

I know it is not all flags. If it were, then I would not have the problem
of displaying it neatly. I believe that this is widespread problem in
packet capture (but you are welcome to contradict me).

If you allow FT_FLAGS_BYTE then FT_FLAGS_HALFWORD and
FT_FLAGS_WORD would follow.

> If the Continuation, Group Trailer, Transmission Trailer, and
> Re-transmission indicator one-bit Boolean bitfields would have that
> type, both the "S" in "FLAGS" and the "BYTE" would be inappropriate, as
> each of them is just one flag, and they have only one bit.

If that is the/your last word on the subject then you have shot down my
idea. Do you feel that you have refuted my contention that flags occur
in 'bunches' (not necessarily in multiples of 8 bits, and not necessarily
adjacent)?

Ben.


--
Leedsnet - The information resource for Leeds and the West Riding
< URL:http://www.leedsnet.com/mobile/ >