关闭

wireshark深入理解

1099人阅读 评论(0) 收藏 举报

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] 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.

7.4.1. Expert Info Entries

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)


7.4.1.1. Severity

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]

7.4.1.2. Group

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.

7.4.1.3. Protocol

The protocol in which the expert info was caused.

7.4.1.4. Summary

Each expert info will also have a short additional text with some further explanation.

7.4.2. “Expert Info” dialog

You can open the expert info dialog by selecting Analyze → Expert Info.

Figure 7.2. The “Expert Info” dialog box

wsug_graphics/ws-expert-infos.png

7.4.2.1. Errors / Warnings / Notes / Chats tabs

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.

7.4.2.2. Details tab

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.

7.4.3. “Colorized” Protocol Details Tree

Figure 7.3. The “Colorized” protocol details tree

wsug_graphics/ws-expert-colored-tree.png

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.

7.4.4. “Expert” Packet List Column (optional)

Figure 7.4. The “Expert” packet list column

wsug_graphics/ws-expert-column.png

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.



0
0
查看评论
发表评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场

wireshark抓包语法

抓取指定IP地址的数据流: 如果你的抓包环境下有很多主机正在通讯,可以考虑使用所观察主机的IP地址来进行过滤。以下为IP地址抓包过滤示例: host 10.3.1.1:抓取发到/来自10.3.1.1的数据流host 2406:da00:ff00::6b16:f02d:抓取发到/来自IPv6地址2...
  • charleslei
  • charleslei
  • 2015-11-10 22:51
  • 815

wireshark怎么抓包、wireshark抓包详细图文教程

wireshark是非常流行的网络封包分析软件,功能十分强大。可以截取各种网络封包,显示网络封包的详细信息。使用wireshark的人必须了解网络协议,否则就看不懂wireshark了。 为了安全考虑,wireshark只能查看封包,而不能修改封包的内容,或者发送封包。 wireshark能...
  • holandstone
  • holandstone
  • 2015-07-23 18:04
  • 83124

Wireshark抓包工具基本用法

下载和安装好Wireshark之后,启动Wireshark并且在接口列表中选择接口名,然后开始在此接口上抓包。例如,如果想要在无线网络上抓取流量,点击无线接口。点击Capture Options可以配置高级属性,但现在无此必要。 点击接口名称之后,就可以看到实时接收的报文。Wiresh...
  • u013628152
  • u013628152
  • 2015-02-27 16:43
  • 1556

Wireshark手机等移动设备抓包

Wireshark手机等移动设备抓包 手机、pad在访问网络时会有数据交换,请求的数据从你的手机上的无线网卡发送出去,经过运营商的各种操作后把该请求数据送到了目的地址——请求数据所在服务器的网卡,服务器经过分析,找到所要请求的数据,验证权限后认可该请求,便开始把所请求的数据打包发送到运营商,各种操...
  • hb255255
  • hb255255
  • 2014-12-11 09:54
  • 6413

windows下wireshark本地回路抓包问题

准备用python的tcp套接字,在网上找了tcp的客户端和服务器的例程,准备测试下效果,比较简单,很快就能通信了。 心血来潮,想用wireshark抓取本地回路的测试包,结果发现怎么都抓不到127.0.0.1的tcp数据包,不管怎么看,都没有127.0.0.1的数据包。呕血弄了一早晨,发现如果是t...
  • dj0379
  • dj0379
  • 2016-10-20 14:52
  • 1912

比Wireshark更轻量、更方便的抓包软件:Charles

Wireshark虽然功能很强大,但学习成本很高,操作很麻烦。Charles是一个非常轻量的软件,简单方便。Request、Response都很清晰,方便查看。
  • lixing333
  • lixing333
  • 2015-01-16 14:38
  • 20477

使用wireshark进行安卓抓包分析

演示使用抓包工具wireshark分析手机lol盒子新闻列表请求地址   wireshark是一款非常强大的开源免费的网络封包分析软件,使用它可以捕获各种网络封包,显示封包的详细信息。 wireshark是一款电脑软件,如何使用它来捕获手机网络数据呢? wireshark的抓包原理是使用W...
  • a997208868
  • a997208868
  • 2015-09-17 14:39
  • 4653

Wireshark和TcpDump抓包分析心得

1. Wireshark与tcpdump介绍  Wireshark是一个网络协议检测工具,支持Windows平台和Unix平台,我一般只在Windows平台下使用Wireshark,如果是Linux的话,我直接用tcpdump了,因为我工作环境中的Linux一般只有字符界面,且一般而言L...
  • qq_29663071
  • qq_29663071
  • 2016-09-01 11:41
  • 935

WireShark基本抓包数据分析

WireShark抓包数据分析: 1、TCP报文格式 源端口、目的端口:16位长。标识出远端和本地的端口号。 顺序号:32位长。表明了发送的数据报的顺序。 确认号:32位长。希望收到的下一个数据报的序列号。 TCP协议数据报头DE 头长:4位长。表明TCP头中包含多少个32位字。 接下来的...
  • youxiansanren
  • youxiansanren
  • 2015-09-10 10:54
  • 3568

WireShark 抓包问题集

在主机和虚拟机之间进行抓包联系,虚拟机的网卡设置为网桥模式,复制物理网络连接状态。 发现每一个包都会重复,原因在于虚拟机使用是和物理机一样的同一块物理网卡,所以不同于两天实体机之间,相当于每个包在发送端和接收端都被抓取到,在我的机器上前后相差的时间在3 * 10 -6s 之内。 对于重复的包,Wir...
  • zhouguoqionghai
  • zhouguoqionghai
  • 2017-05-25 09:26
  • 2755
    个人资料
    • 访问:682212次
    • 积分:7871
    • 等级:
    • 排名:第3114名
    • 原创:411篇
    • 转载:436篇
    • 译文:0篇
    • 评论:55条
    文章分类
    最新评论