On 7/8/05, packet steve <packetsteve@xxxxxxxxxxx> wrote:
> Exposing derived values (e.g,. ip.checksum_bad) likely increases the
> vertical space used for verbose displays. More scrolling around, more
> confusing to read. Would the display add 4 lines?
No I meant that only one of these
booleans would be displayed at a time.
Not all four, just one of them.
So it would just one extra line in the dissect pane.
From
> Window size: 1234
> Checksum: 0xad84 (correct)
> to
> Window size: 1234
> Checksum: 0xad84 (correct)
> (derived) tcp.checksum.good [TCP Checksum is good]
> (derived) tcp.checksum.bad [TCP Checksum is wrong]
> (derived) tcp.checksum.disabled [TCP checksum checking is disabled in
> preferences and not
> checked]
> (derived) tcp.checksum.short_packet [TCP checksum is not checked since
> the packet is short]
> or something similar? Looks messy.
>
> It may not always be obvious where to list a hidden field within the text.
>
> How about a global preference that controls whether hidden fields are
> exposed?
>
>
>
>
> >From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
> >Reply-To: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>,Ethereal development
> ><ethereal-dev@xxxxxxxxxxxx>
> >To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
> >Subject: [Ethereal-dev] Re: Is the hiding of protocol fields (e.g.
> >badchecksum) in general a good idea?
> >Date: Fri, 8 Jul 2005 17:39:08 -0400
> >
> >I agree 100%
> >
> >In my view we should never use hidden fields.
> >
> >There is in my opinion a very good practical and useability reason for
> >not using hidden fields:
> >There are now so many fields managed by Ethereal so it is just not
> >ptractical to go look in the list-of-fields list.
> >Therefore the only way to find out about fields are by looking at
> >where they are used in the decode pane.
> >
> >So I would suggest something like this for the checksum field :
> >
> >Make Checksum an expansion
> > - Checksum 0x1234 (correct)
> > [boolean flag field]
> >
> >Let the boolean field under checksum be a GENERATED field and let it
> >be one out of these four :
> > tcp.checksum.good [TCP Checksum is good]
> > tcp.checksum.bad [TCP Checksum is wrong]
> > tcp.checksum.disabled [TCP checksum checking is disabled in
> >preferences and not checked]
> > tcp.checksum.short_packet [TCP checksum is not checked since the
> >packet is short]
> >
> >
> >In the same way I think IP SRV and IP DST should be an expansion and show
> >the hidden field ip.addr as a generated field inside that expansion.
> >
> >
> >
> >This makes it possible to see and learn about these useful fields by
> >just looking at real packets in the decode pane.
> >
> >
> >On 7/8/05, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> > >
> > > Hi List!
> > >
> > > I'm currently looking at the checksum protocol fields. For example, the
>
> >TCP
> > > checksum will usually look like:
> > >
> > > Checksum: 0x5424 [correct]
> > >
> > > and if it's bad:
> > >
> > > Checksum: 0x5424 [incorrect, should be 0x1234]
> > >
> > > In this case, a hidden boolean field is added to be able to filter on
> >this
> > > item (e.g. to see only "bad checksummed" packets).
> > >
> > > Question: Why do we hide this field at all?
> > >
> > > I don't see any good reason to hide this (and alike) fields. If someone
> > > wants to use it, he must *know* that it's available and must *know*
> it's
> > > name. This doesn't seem to be very intuitive.
> > >
> > > Is there any reason I'm too blind to see?
> > >
> > > IMO this field should be visible and marked as generated, so it will
> >look
> > > like: [Bad Checksum: True]
> > >
> > > Regards, ULFL
> > >
> > > P.S: The same *may* apply to most (all?) other hidden fields as well?!?
> > >
> >_________________________________________________________________________
> > > Mit der Gruppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle
> > > Freunde gleichzeitig schicken:
> >http://freemail.web.de/features/?mc=021179
> > >
> > >
> > >
> > > _______________________________________________
> > > Ethereal-dev mailing list
> > > Ethereal-dev@xxxxxxxxxxxx
> > > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> > >
> >
> >_______________________________________________
> >Ethereal-dev mailing list
> >Ethereal-dev@xxxxxxxxxxxx
> >http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
>
