Ethereal-dev: Re: [Ethereal-dev] No further comments on the 'User's guide'preview?!?

Note: This archive is from the project's previous web site, This list is no longer active.

From: Ulf Lamping <[email protected]>
Date: Thu, 29 Jul 2004 20:54:17 +0200
Olivier Biot wrote:

>| Chapter 6.3 (page 93 -94) Building display filter expressions
>| -------------------------------------------------------------
>| * Explain why the filter "ip.addr !="  normally isn't as
>useful as "ip and !(ip.addr =="
>Here's some input:
>There is one important thing to remember with display filter
>expressions. Whenever a protocol field appears in a filter expression,
>an implicit "exists" test is performed. This means that an expression
>like "ip.addr !=" does *not* do what you would expect from it.
>Instead, that expression will even be true for packets where either
>source or destination IP address equal "". The reason for this,
>is that the expression "ip.addr !=" must be read as "the
>(reassembled) packet contains a field named ip.addr with a value
>different from". As an IP datagram contains both a source and
>a destination address, the expression will evaluate to true whenever
>at least one of the two addresses differs from If you want to
>filter out all packets containing IP datagras to or from IP address
>, then the correct filter is "! (ip.addr ==" as it
>reads "show me all the (reassembled) packets for which it is not true
>that a field named ip.addr exists with a value of", or in
>other words, "filter out all (reassembled) packets for which there are
>no occurrences of a filed named ip.addr with the value".

I've added a "A common mistake" section describing the problem.
I've also started a new section "Display filter fields", which was missing and still is incomplete.
>| Chapter 7.3  (page 110) Packet Reassembling
>| ------------------------------------------------
>| * Mention that you may have to change some preference settings for
>(IP/TCP,...) in order to get packet
>| reasembly to work
>Here's some input:
>Reassembly in protocols requires two things.
>First of all, the lower level protocol (e.g., TCP) must support
>reassembly. Often this reassembly can be enabled or disabled at will
>via the protocol preferences.
>Secondly, the higher level protocol (e.g., HTTP) must use the
>reassembly mechanism to reassemble fragmented protocol data. This too
>can often be enabled or disabled via the protocol preferences.
>As a result, if reassembly of protocol Y on top of protocol X must be
>enabled, it is wise to take a look at the protocol preferences for
>both protocols and check whether protocol X allows subdissectors to
>reassemble (see for example TCP and UDP), and check whether protocol Y
>supports reassembly and has it enabled.
I've tried to include your info, but don't like the result I got. I'll have to rework this chapter again.