Olivier Biot wrote:
>| Chapter 6.3 (page 93 -94) Building display filter expressions
>| -------------------------------------------------------------
>| * Explain why the filter "ip.addr != 10.10.20.10" normally isn't as
>useful as "ip and !(ip.addr == 10.10.20.10)"
>
>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 != 1.2.3.4" 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 "1.2.3.4". The reason for this,
>is that the expression "ip.addr != 1.2.3.4" must be read as "the
>(reassembled) packet contains a field named ip.addr with a value
>different from 1.2.3.4". 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 1.2.3.4. If you want to
>filter out all packets containing IP datagras to or from IP address
>1.2.3.4, then the correct filter is "! (ip.addr == 1.2.3.4)" 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 1.2.3.4", or in
>other words, "filter out all (reassembled) packets for which there are
>no occurrences of a filed named ip.addr with the value 1.2.3.4".
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.