Ethereal-dev: Re: [Ethereal-dev] No further comments on the "User's guide"preview?!?
From: Martin Regner
| Ulf lamping wrote:
| > I've checked in the sources of the "Ethereal User's Guide" about a
week ago.
| >
| > I've got only two review comments (ok, I understand it's holiday
time)!
| >
| > A pdf version of the document is still available at:
| >
| > http://lamping.net/ethereal/user-guide.pdf
| >
| > Will anyone else do a review on the document in the near future,
or do
| > we want to release it in it's current state?
[snip]
| 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".
|
|
| 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.
Best regards,
Olivier
