7.4. Expert Information
The expert infos is a kind of log of the anomalies found by Wireshark in a capture file.
The general idea behind the following “Expert Info” is to have a better display of “uncommon” or just notable network behaviour. This way, both novice and expert users will hopefully find probable network problems a lot faster, compared to scanning the packet list “manually” .
![[Warning]](https://i-blog.csdnimg.cn/blog_migrate/feacf755522e55950482698dc6d2d531.png) | Expert infos are only a hint |
|---|---|
| Take expert infos as a hint what’s worth looking at, but not more. For example, the absence of expert infos doesn’t necessarily mean everything is OK. |
The amount of expert infos largely depends on the protocol being used. While some common protocols like TCP/IP will show detailed expert infos, most other protocols currently won’t show any expert infos at all.
The following will first describe the components of a single expert info, then the User Interface.
Each expert info will contain the following things which will be described in detail below.
Table 7.1. Some example expert infos
| Packet # | Severity | Group | Protocol | Summary |
|---|---|---|---|---|
| 1 | Note | Sequence | TCP | Duplicate ACK (#1) |
| 2 | Chat | Sequence | TCP | Connection reset (RST) |
| 8 | Note | Sequence | TCP | Keep-Alive |
| 9 | Warn | Sequence | TCP | Fast retransmission (suspected) |
Every expert info has a specific severity level. The following severity levels are used, in parentheses are the colors in which the items will be marked in the GUI:
- Chat (grey): information about usual workflow, e.g. a TCP packet with the SYN flag set
- Note (cyan): notable things, e.g. an application returned an “usual” error code like HTTP 404
- Warn (yellow): warning, e.g. application returned an “unusual” error code like a connection problem
- Error (red): serious problem, e.g. [Malformed Packet]
There are some common groups of expert infos. The following are currently implemented:
- Checksum: a checksum was invalid
- Sequence: protocol sequence suspicious, e.g. sequence wasn’t continuous or a retransmission was detected or …
- Response Code: problem with application response code, e.g. HTTP 404 page not found
- Request Code: an application request (e.g. File Handle == x), usually Chat level
- Undecoded: dissector incomplete or data can’t be decoded for other reasons
- Reassemble: problems while reassembling, e.g. not all fragments were available or an exception happened while reassembling
- Protocol: violation of protocol specs (e.g. invalid field values or illegal lengths), dissection of this packet is probably continued
- Malformed: malformed packet or dissector has a bug, dissection of this packet aborted
- Debug: debugging (should not occur in release versions)
It’s possible that more groups will be added in the future.
You can open the expert info dialog by selecting → .
An easy and quick way to find the most interesting infos (rather than using the Details tab), is to have a look at the separate tabs for each severity level. As the tab label also contains the number of existing entries, it’s easy to find the tab with the most important entries.
There are usually a lot of identical expert infos only differing in the packet number. These identical infos will be combined into a single line - with a count column showing how often they appeared in the capture file. Clicking on the plus sign shows the individual packet numbers in a tree view.
The Details tab provides the expert infos in a “log like” view, each entry on its own line (much like the packet list). As the amount of expert infos for a capture file can easily become very large, getting an idea of the interesting infos with this view can take quite a while. The advantage of this tab is to have all entries in the sequence as they appeared, this is sometimes a help to pinpoint problems.
The protocol field causing an expert info is colorized, e.g. uses a cyan background for a note severity level. This color is propagated to the toplevel protocol item in the tree, so it’s easy to find the field that caused the expert info.
For the example screenshot above, the IP “Time to live” value is very low (only 1), so the corresponding protocol field is marked with a cyan background. To easier find that item in the packet tree, the IP protocol toplevel item is marked cyan as well.
An optional “Expert Info Severity” packet list column is available that displays the most significant severity of a packet or stays empty if everything seems OK. This column is not displayed by default but can be easily added using the Preferences Columns page described in Section 10.5, “Preferences”.
Definition of the Differentiated Services Field
On Wednesday 05 October 2011 08:35:42 Guy Harris wrote: > On Oct 4, 2011, at 10:38 PM, Lisi wrote: > > I understand (I hope!) that the differentiated services field tells you a > > packet's priority, but I can't work out how to read it. Does nothing but > > zeros (e.g. DSCP 0x00) mean that this particular trace has no priority > > set? Or does it mean the reverse? (Top priority.) > > RFC 2474 "Definition of the Differentiated Services Field (DS Field) in the > IPv4 and IPv6 Headers" says > > The DS field structure is presented below: > > > 0 1 2 3 4 5 6 7 > +---+---+---+---+---+---+---+---+ > > | DSCP | CU | > > +---+---+---+---+---+---+---+---+ > > DSCP: differentiated services codepoint > CU: currently unused > > and > > 4.1 A Default PHB > > > A "default" PHB MUST be available in a DS-compliant node. This is > the common, best-effort forwarding behavior available in existing > routers as standardized in [RFC1812]. When no other agreements are > in place, it is assumed that packets belong to this aggregate. Such > packets MAY be sent into a network without adhering to any particular > rules and the network will deliver as many of these packets as > possible and as soon as possible, subject to other resource policy > constraints. A reasonable implementation of this PHB would be a > queueing discipline that sends packets of this aggregate whenever the > output link is not required to satisfy another PHB. A reasonable > policy for constructing services would ensure that the aggregate was > not "starved". This could be enforced by a mechanism in each node > that reserves some minimal resources (e.g, buffers, bandwidth) for > Default behavior aggregates. This permits senders that are not > differentiated services-aware to continue to use the network in the > same manner as today. The impact of the introduction of > differentiated services into a domain on the service expectations of > its customers and peers is a complex matter involving policy > decisions by the domain and is outside the scope of this document. > The RECOMMENDED codepoint for the Default PHB is the bit pattern ' > 000000'; the value '000000' MUST map to a PHB that meets these > specifications. The codepoint chosen for Default behavior is > compatible with existing practice [RFC791]. Where a codepoint is not > mapped to a standardized or local use PHB, it SHOULD be mapped to the > Default PHB. > > A packet initially marked for the Default behavior MAY be re-marked > with another codepoint as it passes a boundary into a DS domain so > that it will be forwarded using a different PHB within that domain, > possibly subject to some negotiated agreement between the peering > domains. > > so, at least by default, it means "no special priority". (In this context, > PHB means "per-hop behavior": > > http://en.wikipedia.org/wiki/Per-Hop_Behaviour Thanks, Guy. That is very helpful of you.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
