特权同学

【技术分享】以太网,FPGA就一定能搞定系列之MACRAW模式下的ARP请求

0
阅读(3758)

以太网,FPGA就一定能搞定系列之MACRAW模式下的ARP请求

本系列博文节选自特权同学的FPGA开发电子书《SF-CY3 FPGA套件开发指南》。

最新设计文档下载地址:http://pan.baidu.com/s/1em79m

1 概述

如图所示,这是本实例的硬件架构和互联示意图。上一节对整个架构已经有所介绍,这里不重复描述。由于上一节只是简单的验证FPGACH395之间的通信状态,而没有涉及以太网通信应用,而这一节我们需要连接网络,进行实际的以太网通信测试。所以,在本实例中,大家需要使用网线将SF-NET子板的以太网接口连接到路由器(当然了,也必须确保PC机连接到了同一个路由器上)或者直接连接到PC机上。

TCP/IP协议是网络的基础,是Internet的语言,可以说没有TCP/IP协议就没有互联网的今天。网络的速度发展非常快,学习网络的人也越来越多。而本教程将会通过使用FPGA驱动PHY/MAC集成芯片CH395进行各种以太网通信,来和大家一起认识并掌握TCP/IP以及其他常用的以太网协议,甚至能够达到学以致用的水平。这里我们先扫盲式的和大家一起认识一下以太网分层和帧协议内容。

网络协议通常分不同层次进行开发,每一层分别负责不同的通信功能。一个协议族,比如TCP/IP,是一组不同层次上的多个协议的组合。TCP/IP通常被认为是一个四层协议系统,如图所示。

每一层负责不同的功能:

1)链路层,有时也称作数据链路层或网络接口层,通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆(或其他任何传输媒介)的物理接口细节。

2)网络层,有时也称作互联网层,处理分组在网络中的活动,例如分组的选路。在TCP/IP协议族中,网络层协议包括IP协议(网际协议),ICMP协议(Internet互联网控制报文协议),以及IGMP协议(Internet组管理协议)。

3)运输层主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中,有两个互不相同的传输协议:TCP(传输控制协议)和UDP(用户数据报协议)。TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层,确认接收到的分组,设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信,因此应用层可以忽略所有这些细节。而另一方面,UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机,但并不保证该数据报能到达另一端。任何必需的可靠性必须由应用层来提供。这两种运输层协议分别在不同的应用程序中有不同的用途,这一点将在后面看到。

4 )应用层负责处理特定的应用程序细节。如Telnet远程登录、FTP文件传输协议、SMTP简单邮件传送协议、SNMP简单网络管理协议等。

当目的主机收到一个以太网数据帧时,数据就开始从协议栈中由底向上升,同时去掉各

层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识,以确定接收数据的

上层协议。这个过程称作分用(Demultiplexing),如图展示了该过程是如何发生的。

对于以太网协议的分层是一件比较头疼的事情,比如为协议I C M PI G M P的定位。在前面的分层中,我们把它们与IP放在同一层上,那是因为事实上它们是IP的附属协议。但是在这里,我们又把它们放在IP层的上面,这是因为ICMPIGMP报文都被封装在IP数据报中。

对于ARPRARP,我们也遇到类似的难题。在这里把它们放在以太网设备驱动程序的上方,这是因为它们和IP数据报一样,都有各自的以太网数据帧类型。但在某些分层中,我们可能会把ARPRARP作为以太网设备驱动程序的一部分,放在IP层的下面,其原因在逻辑上却是合理的。

3 CH395应用概述

CH395内部集成了IPv4ARPICMPIGMPUDPTCP等协议,其关系如图所示。

TCPUDP是两种比较重要的传输层协议,两者都使用IP作为网络层协议。

TCP是一种面向连接的传输,能够提供可靠的字节流传输服务。

UDP是一种简单的面向数据报的运输层协议,与TCP不同的是UDP无法保证数据报文准确达到目的地。

TCP为网络设备提供了高可靠性的通讯,它所做的工作包括把应用程序交给他的数据分成合适的小块交给下面的网络层,确认接收到的分组,设置超时时钟等,由于运输层提供了高可靠性的端到端的通信,应用层客户忽略所有细节。而UDP则为应用层提供一种非常简单的服务,速度较TCP快,它只是把数据报从一个网络终端发送到另一个网络终端,但是并不保证该数据报能够达到另一端,任何必需的可靠性都必须由应用层来提供。

IP是网络层上的协议,同时被TCPUDP使用,TCPUDP的每组数据都通过IP层在网络中进行传输。

ICMPIP协议的附属协议,IP层用它来与其他主机或者路由器交换错误报文或者其他重要信息,例如CH395产生不可达中断,就是通过ICMP来进行错误报文交换的。PING也使用了ICMP协议。

IGMPInternet组管理协议,主要用来把一个UDP数据报多播到多个主机。

ARP为地址解析协议,用来转换IP层和网络接口层使用的地址。

CH395提供了MACRAW传输模式、IPRAW传输模式、UDP传输模式、TCP客户端模式、TCP服务器模式、DHCP传输模式和PPPOE传输模式。各个模式下,数据流基本都是相应模式所支持协议的有效数据,可以满足用户的各种不同应用需求。我们将会使用该SF-CY3核心板和SF-NET子板对各种不同的传输模式进行测试,给出各种以太网传输协议的实例。

4 MACRAW模式介绍

MACRAW模式下,CH395会透明传输以太网和单片机之间的数据,不会对数据进行TCP/IP封装,CH395接收数据时会对以太网冗余校验CRC32进行校验,如果校验错误,数据包不会转发给单片机。CH395发送数据时会在数据包尾部加入以太网冗余校验CRC32。单片机每次向CH395写入的数据长度不得大于1514CH395会将单片机每次写入的数据封装成一帧数据进行发送。当CH395从以太网收到数据后会通知单片机,此时单片机应立即将所有数据从CH395内部接收缓冲区读走。仅Socket0可以设置此模式,且其他Socket将不可用。如图所示,对于一个标准的IEEE802.3以太网帧而言,MACRAW模式下,用户可以通过编程读写的数据流包括了目的MAC地址、源MAC地址、协议类型和有效数据等内容,CRC32数据则由CH395芯片自动给出。

我们可以简单的来看看前面所提到的ARPRARP协议的数据帧格式,如图所示。我们就重点看看ARP协议,这是一个地址解析协议,简单讲,就是以太网目的主机和源主机之间进行握手寻址的一个协议机制。ARP协议由三大部分数据内容组成,第一部分是以太网首部,分别传输6个字节的目的MAC地址和6个字节的本机MAC地址;第二部分是有效传输数据,头两个字节用于区分不同的协议类型,如IP协议对应两个字节16进制的0800ARP协议则对应为0806,如果确定是ARP协议传输,那么随后的28个字节为ARP的请求或应答帧数据,具体帧定义后面会讨论,由于IEEE802.3以太网帧协议规定,有效数据传输最少必须是46个字节,而ARP的请求或应答帧只有28个字节,因此后续必须填充18个字节数据,这18个字节一般以全零数据填充;第三部分则是CRC校验数据,通常由芯片自动计算给出。

5 ARP简介

我们后面希望通过发出一个ARP请求,然后看看PC端传回来的ARP应答,验证MAC的功能。先来简单的了解ARP请求的帧格式。

下面是我们要发送给笔者测试PC机的60ByteARP请求数据,正好可以对照上面给出的ARP帧请求定义。

//以太网首部(14Byte

0000: ff ff ff ff ff ff //目的主机为广播地址

0006: 84 c2 e4 f0 08 ef //源主机MAC地址为84-C2-E4-F0-08-EF

000c: 08 06 //上层协议类型0x0806表示ARP或RARP

//ARP请求(28Byte

000e: 00 01 //硬件类型0x0001表示以太网

0010:08 00 //协议类型0x0800表示IP协议

0012:06 04 //MAC地址长度为6; IP地址长度为4

0014:00 01 //op为0x0001表示请求目的主机的MAC地址

0016: 84 c2 e4 f0 08 ef //源主机MAC地址为00-1C-23-17-4A-CB

001c: c0 a8 01 65 //源主机IP地址(192.168.1.101

0020: 00 00 00 00 00 00 //目的主机MAC地址未知,全0待填写

0026: c0 a8 01 67 //目的主机的IP地址(192.168.1.103

//填充数据(18Byte)填充aoc c0 a8 01 000

002c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

003c: 00 00

目的主机便是我们的PC,它的MAC地址和IP地址都不是瞎编的,在目标PCstartàcmd中敲击“ipconfig /all”命令,如图所示。我们可以看到这个目标主机的MAC地址为2C-27-D7-1F-1D-E1IP地址为192.168.1.103。假设我们只知道目的主机的IP地址,而不知道MAC地址,那么上面的ARP请求中就给出目的主机的IP地址,但使用广播MAC地址进行寻址。理论上,目的主机在接收到对他的ARP请求后,会产生一个ARP应答帧给源主机,实际是否如此,随后我们便可验证。

6 软件设计

该实例的软件流程如图所示,除了一系列的初始化外,main函数中不断的发送ARP请求帧,PC机通常会回复ARP应答,而连接FPGA的输入GIOCH395中断信号会产生相应中断,main函数中相应的轮询处理中断,将接收到的ARP应答帧通过JTAG UART打印到Nios II Console中。

7 板级调试

下一步,该连接的连接,该下载的下载,该运行的运行……在一切就绪之后,我们可以来确认一下EDSNios II Console打印的收发数据帧,如图所示。

FPGA发送的ARP请求,数据如下:

0xff,0xff,0xff,0xff,0xff,0xff,0x84,0xc2,0xe4,0xf0,0x08,0xef,0x08,0x06,0x00,0x01,0x08,0x00,0x06,0x04,0x00,0x01,0x84,0xc2,0xe4,0xf0,0x08,0xef,0xc0,0xa8,0x01,0x65,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0xa8,0x01,0x67,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

FPGA接收到的ARP应答,数据如下:

0x84,0xc2,0xe4,0xf0,0x08,0xef,0x2c,0x27,0xd7,0x1f,0x1d,0xe1,0x08,0x06,0x00,0x01,0x08,0x00,0x06,0x04,0x00,0x02,0x2c,0x27,0xd7,0x1f,0x1d,0xe1,0xc0,0xa8,0x01,0x67,0x84,0xc2,0xe4,0xf0,0x08,0xef,0xc0,0xa8,0x01,0x65,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,

FPGA发出的ARP请求前面我们已经做了解析,而ARP应答是PC端发送回来的,我们不妨也分析下它的帧结构。

//以太网首部(14Byte

0000: 84 c2 e4 f0 08 ef //目的主机(FPGA端)MAC地址84-C2-E4-F0-08-EF

0006: 2c 27 d7 1f 1d e1 //源主机(PC端)MAC地址为2C-27-D7-1F-1D-E1

000c: 08 06 //上层协议类型0x0806表示ARP请求或应答

//ARP请求(28Byte

000e: 00 01 //硬件类型0x0001表示以太网

0010:08 00 //协议类型0x0800表示IP协议

0012:06 04 //MAC地址长度为6; IP地址长度为4

0014:00 02 //op为0x0002表示ARP应答

0016: 2c 27 d7 1f 1d e1 //源主机(PC端)MAC地址为2C-27-D7-1F-1D-E1

001c: c0 a8 01 67 //源主机(PC端)IP地址(192.168.1.103)

0020: 84 c2 e4 f0 08 ef //目的主机(FPGA端)MAC地址84-C2-E4-F0-08-EF

0026: c0 a8 01 65 //目的主机(FPGA端)的IP地址(192.168.1.101

//填充数据(18Byte)填充aoc c0 a8 01 000

002c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

003c: 00 00

回到目标PC机,我们在cmd命令行中,输入一个命令“arp -a”,此时,我们看到发出ARP请求的源主机已经出现在了它的动态列表中了,而且IPMAC与发出ARP请求的FPGA端给出的别无二致。

最后,我们再借助一个抓包工具“科来网络分析系统”来解析下FPGA发过来的ARP请求帧。“科来网络分析系统”可以到官方网站(http://www.colasoft.com.cn/download/capsa.php)下载,大家可以选择“技术交流版”进行下载。下载并安装完成后,可以根据提示到他们官方网页注册,接着系统会自动将注册码发送到我们的邮箱中。

如图所示,我们打开已经安装并注册好的科来网络分析系统。选择“本地连接”以及“全面分析”,点击“Start”开始运行。

如图所示,“节点浏览器”中选择“ARP”项,然后双击“物理端点”下的“84:C2:E4:F0:08:EF”(即ARP请求发送端的MAC地址)。

如图所示,这里我们看到了详细的ARP请求帧的协议解析。大家可以比对我们前面给出的ARP请求帧解析,和这里是完全一致的。

Baidu
map