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

[Ben Fowler <wapdev@xxxxxxxxxxxx>]

(Assuming that you want the CC)

> > 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.
>
> I think that would be done by declaring "Continuation" as something such
> as
>         [ ... recipe snipped ]

The best I could get was output like

      . = Continuation: No TPIs
      . = Re-transmission Indicator: Re-transmission

In other words, my flags were always printed left-justified & not in their
position in the larger data-structure.

I will do some more work on this (perhaps) but that may not be for
two to three weeks.

> 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.

Your second point is why I would make the textual description present
but optional. I hope that if we disagree on methods, we agree on goals.

I cannot altogether agree with your third point, it is the protocol's
documentation not ethereal's that needs digging out. My point is that
if someone is  investigating problems with a protocol that he or she
is not intimate with then that individual will need the protocol documentation
anyway (and might still appreciate the brief tag along the lines that
I am thinking). Also I think that the man page contains all the
documentation needed in respect of ethereal..

> > 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.
>
> ...and giving a full dissection might also be useful or even essential.

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. This issue is
the same.

> 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 am wanting to
do flags ( FT_BOOLEAN) a different way. I would rate the bit field as
entirely satisfactory. My problem started with the fact that it
appeared that I could some things with bit fields that I could not do with
booleans, and I felt that improving the boolean type was the best
solution for me. I am now interested in finding out whether there
is wider interest.

>         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.
>
> I wouldn't treat it as being in competition with using FT_BOOLEAN for
> the individual bits at all - I would see them *both* being used.

Yes. There may be difference of perception. I feel that in most cases
the FT_BOOLEAN way becomes 'second best', but your statement
is true that in some cases both might be used.

> Note that, for TCP, we use a different scheme for summarizing the bits
> in a the flags field:
>
>     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

Heck. This is very much what I am trying to do. Maybe I should look
at the tcp code. I did look through the packet-* code before starting
this, but it was a trees and forest issue.

> (I've think I've seen one person praising Ethereal over Microsoft
> Network Monitor, which, in its equivalent of the "Info" field in the
> packet list display, summarizes them with single letters, e.g.
> "...A..S." - he preferred, as I remember, the "SYN, ACK" summary.)
>
> There may be advantages to both - one might well do that as
>
>         Flags: ...A..S. (SYN, ACK)

This is most significant. Yes, I would like to make something
that is more highly rated than the legacy product you mention
(note, if anyone is reading this, I would appreciate some notes
for the Ethereal web site on how ethereal compares with
alternative analysers. When I started with ethereal about 18 months
ago, I think that there was a gap, but I would suggest that
ethereal caught up with commercial offerings around 0.8.3. What
do others think? Do we have any substantiated evidence
either way. Are there any details where ethereal is demonstrably
inferior).

Funnily, I would be happy with the Microsoft way, though I would
give way to anyone who had used it and disliked it; but I would
not like the in between one (SYN, ACK). Once you are using more
than one character for a flag, such as  0/1 or s/S then you need
something that is descriptive. (Arguably SYN is descriptive to a
tcp expert, but at this point I take your side and state that ethereal
must be fully usable by and useful to non-experts). Of course the
(SYN, ACK) syntax is appropriate for the packet summary in the
packet window.

I would definitely be receptive to the opinions of people who have
used more  than one system and have preferences.

> The parenthesized summary could also display the values of multi-bit
> fields, e.g.:
>
>         Header Flags: c... .GTr (Invoke, No re-assembly)

Possibly, but also looks like a prima facie case of the crime of
Procustes in that 'summary' has to be made short. I am not willing
to do that. See above, once you need more than one character
the description must be full (in the sense of useful to a non-expert).
(I think that we agree on this).

> or, as we do now for the Control field in SDLC-derived protocols:
>
>         Control field: U, func = UI (0x03)
>            000. 00.. = Unnumbered Information
>            .... ..11 = Unnumbered frame
>
> (although the parenthesized value there is the raw hex value).

This is good. I need to achieve something like that.

> [ ... ]
>
> That sounds as if it might be the right way to do it, e.g.:
>
>        Header Flags
>        c... .GTr
>        0... .... = Continuation: absent
>        .000 1... = PDU Type: Invoke
>        .... .11. = Trailer flags: Packet re-assembly not supported
>        .... ...0 = Retransmission: no retransmission

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).

> > > 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 ...
>
> Sorry, I perhaps didn't make myself clear - that question wasn't a
> rhetorical question intended to say there's no point for the feature,

I apologise. I had indeed read it that way.

> ... it
> was a technical question asking what its precise semantics were, i.e.
> what would the protocol tree code put into the tree for it, and what
> would it put into the display for it?

I spent most of the 12 hours between 1900 last night and 0700 this
a.m. fiddling with proto.h so I didn't get onto that (& may not for another
week or so), but my basic idea is to put into the code an 8 character
string like "C....GTR" and have the display make use of toupper/tolower.

> It wasn't clear to me whether you intended to make it the type for the
> entire flags field, or for individual one-bit Boolean bitfields in that
> field.  It sounds now as if you intended it to be the type for the
> former, rather than the latter.

Yes. Of course it may be sparse.

> > If you allow FT_FLAGS_BYTE then FT_FLAGS_HALFWORD and
> > FT_FLAGS_WORD would follow.
>
> Then perhaps they should be FT_FLAGS_UINTn, or FT_FLAGS_n, or something
> such as that, along the lines of the FT_UINTn field types.

This is at your discretion. Actually if I had written the code before I had
thought of the name, I might have chosen FT_FLAGS_UNIT8 et cetera.

Obviously I have made a few changes to the dfilter* files as well.

I may be unable to produce code good enough for other people to see until
0.8.7 is out and stable.

Ben.

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