PROFINET协议-DCP实践

     这里就上篇文章《Profinet协议解析-DCP》内容进行实践，通过实验验证各操作的准确性，并且也介绍一些基本的通信分析方法，不必使用昂贵的抓包工具（某东200左右），使之成为人人触手可及的实验方式。

       搞这个东西的，基本都属于工控行业。，目前国内的工控业属于比较苦逼的行业，当然只限于研发相关岗位，毕竟这是那部分干活的人，说好听点就是为工控业崛起而奋斗。所以吧大家手上也没有多少money，就提供一种简陋的方式，公司有工具的另说。有人可能会问为什么不让公司提供或购买？话说当采购流程这个垃圾告诉你以年为单位时，或许你就不这么问了。别等青春已逝，一事无成。

 

工具：管理型交换机，PLC（可选），PN设备一台，PC一台

软件：Wireshark

 图1 交换机要求标题

 

       如图1所示，带有端口镜像的交换机。这里的端口镜像就是其本意，将某个端口镜像到另外一个端口，这样就可以监听该端口上的所有流量，因为交换机相比集线器最大的优势就是实现定向的端口转发，而不是广播到所有的端口，最大程度上避免了网络风暴。这也给网络监听带来了麻烦的地方，比如如图2所示，控制器在端口2，PN设备在端口1，两个设备间正常交换数据，在PC机上监听不到任何数据，除了广播帧，而端口镜像恰好可以无条件的将数据转发过来。最好再支持VLAN的，后面可以用来做VLAN相关的实验验证。好了，准备好上述设备，基本就可以完成本章所涉及的实验。首先按照图2所示，连接所有的设备。

图2 网络拓扑

 

       控制器和PN设备连接1号和2号端口，PC连接在另外一个端口4，通过交换机web管理界面，将端口1或者2（数据相同）镜像到端口4。在PC上启动Wireshark，如图3所示，选择监听网卡，开始就可以了。根据自己的需要抓取相应的数据包后就可以停止捕获，为一下步筛选数据包节约时间。抓取后的数据包如图4所示，这里我以抓包的示例为主，介绍上一节的DCP相关数据帧。

图3 wireshark界面

 

图4 wireshark抓包结果

 

 

              当拿到数据包后，会发现有许多的帧，比起Ethercat，Canopen要多很多。原因就是Profinet兼容以太网，所以里面有ARP协议帧，LLDP邻居信息传递，DHCP域名解析，TCP握手帧，IPV4和IPv6等等在以太网上出现的协议帧。为了便于拿到我们需要的，首先要进行数据包过滤，我们这里要分析dcp帧，所以直接用“pn_dcp”筛选出这类数据，如图5所示。这是DCP-Identify识别帧，《Profinet协议解析-DCP》这篇文章中介绍的第三部分，两帧数据，一帧由plc发送给PN设备，另一帧由PN设备做出相应。

图5 DCP数据帧

 

       如图6所示，为PLC向网络中广播的一帧数据，我们可以看到源地址为PLC，目的地址为PN的广播域，Ethernet类型为0x8892（Profinet）。帧的ID为0xFEFE, 属于DCP-Req。再往下一部分为DPC主要的内容区域-DCPblock，这里有询问的设备名称，这个设备名称来源于下载到PLC的组态。这就是为什么当组态中的名称与实际不符时，PLC无法连接的原因，在网络上只有设备名称相同的才会响应这帧数据。这一点类同于我们的域名一样，方便好记比较人性化，当然还有一个很重要的原因域名所属权在个人，IP所属权为NIC组织。如果在组态中允许输入设备mac地址，理论上就可以直接建立连接。在DCP-Block中，可以看到上一篇文章中提到的ServiceID，ServiceType，Xid等字段。

关于设备名称和设备转换名称，这里单独解释一下。这里的设备名称需要特别注意，“xn--xb1aa0f-lm1lh944c”这并不是组态中的设备名称，实际名称是“驱动xb1aa0f”。在博图组态中我们看到的设备名称就是可视化，但是网络中所看到的是转化后的名称，有了这层转化关系，我们就可以给设备任意起名，肆意妄为哈哈。那么为什么要存在这种转换关系？这还是回归到Profinet一网到底的理念上，它要兼容以太网，那么作为这种转换，就自然需要参考以太网相关的规范，上面提到过设备名称和域名的类比，这里同样是任意字符或多语言域名规范化。之前的域名是除了“-”外不允许任何特殊字符，而现在还出现了中文域名等地方语言的域名，那么浏览器是怎么识别的，毕竟不可能同时升级全球的DNS协议，必然存在一种转化方式，使之兼容以前的域名规则，这里的设备名称同样采用了这种方式，有兴趣的可以按照协议规范转化一下，不过规范晦涩难懂，主要参考RFC3490，3491，3492，3494规范。有兴趣可以了解一下，附标准库：https://datatracker.ietf.org/。

               

图6 Identify-PLC

 

       言归正传，PLC发出了问询，那么就需要响应的设备进行答复。如图7所示，为设备名称为“驱动xb1aa0f“的伺服响应数据帧。这个数据帧一般都比较长，所以这里以block为单元整合展示，不再展开了。包括有设备名称，设备ID，IP地址，设备厂家，设备类型，设备优先级等。PLC收到这帧数据就会和组态进行核实，如果符合就认可这台设备；如果不符合就会报错，或重新分配相关参数。

图7 DCP-Identify响应帧

 

       那么有玩过总线设备的小伙伴可能知道设备的ip相关参数怎么设置的。这里涉及到plc的启动方式。其实有两种情况，一种是已经设置了ip，且符合组态数据。另一种是未分配ip，那么plc会用已返回的合法ip试图建立连接，如果超时则重新分配相关参数。后面可能单独一篇文章讲一讲plc启动过程中都在干什么？为什么有时候启动快？有时候启动就慢？设备数量真的时最大影响因素吗？

       因为篇幅有限，只展示了识别帧的举例，小伙伴们可以自己抓帧对着上一篇文章看一看profinet设备间是怎么交流的。这里特别解释一下，在DCP帧里面我按最简单的情况下进行的帧字段分析，有可能在实际中发现有额外的数据，这是很正常的，一个大的协议族还要兼容以太网，断然不是简单的几页就可以囊括其中。另外文章中有不对的地方，欢迎在《遥远的星星》本人博客中评论指正,共同交流。

附：blog.csdn.net/zh_666888/

2020-12-20