基于TUNTAP非标卡虚拟化实现.docVIP

基于TUNTAP非标卡虚拟化实现 　　摘 要 针对一些特定应用所开发的通信/控制板卡无法当作普通网卡来使用的问题，提出了一种基于TUN/TAP的解决方法，该方法为非标卡创建一个对应的TUN/TAP设备，用一个转发线程来连接TUN/TAP设备与非标卡驱动模块，并在该线程中实现对底层硬件操作细节的屏蔽。应用该方法后，即采用标准的Socket接口进行非标卡上层应用的开发。 　　关键词 TUN/TAP；虚拟化；网卡；Socket 　　中图分类号：TP311.1 文献标识码：A 文章编号：1671-7597（2015）03-0058-02 　　一些特殊情况下，出于需求及复杂性等因素，开发出来的通信/控制卡与普通的标准网卡存在差异，无法直接当作普通网卡操作，虽然满足了特殊应用，却给上层应用开发带来了不便。 　　TUN/TAP是操作系统内核中的虚拟网络设备，不同于普通靠硬件网卡实现的设备，这些虚拟网络设备完全用软件实现，具有与硬件的网络设备完全相同的功能，在用户空间的程序看来，与普通网卡无异，并且可以利用Ethereal、Wireshark等工具进行抓包处理。 　　TUN/TAP支持主流的系统平台，包括Windows、Linux、Mac OS X、FreeBSD、OpenBSD、Solaris OS等。 　　基于上述特点，利用其实现非标卡的虚拟化，可以很好地解决此类设备软件开发中的诸多不便。 　　1 TUN/TAP工作原理 　　TUN/TAP本身是作为驱动模块运行在操作系统内核模式下。其中，TUN模拟了点对点的网络设备，封装对象是第三层数据包；TAP等同于以太网设备，封装对象是第二层数据包。 　　TUN/TAP驱动包括网卡驱动和字符驱动两部分。网卡驱动与TCP/IP协议栈对接，提供以Socket方式访问TUN/TAP设备的通道；字符设备驱动提供以普通文件方式访问TUN/TAP设备的通道；两者在TUN/TAP内部完成交互。这样就为Socket接口与普通文件读写接口之间建立起了一座桥梁，实现了数据的双向流通。 　　从使用者角度看，TUN/TAP既可当作普通网卡来访问，也可当作普通文件来访问。 　　图 1 TUN/TAP工作原理 　　如图1，TUN/TAP中存在两条数据流通道： 　　1）调用write/WriteFile写入数据，经TUN/TAP处理后注入到TCP/IP协议栈，通过Socket负责接收的接口函数进行 　　接收； 　　2）调用Socket负责发送的接口函数写入数据，经TCP/IP协议栈后再通过TUN/TAP处理，通过read/ReadFile进行接收。 　　通常，TUN/TAP作为虚拟网卡设备，并不直接和真实的物理板卡交换数据，而是通过字符驱动和一个用户模式下的应用程序进行交互，再由应用程序实现与物理板卡之间的通信。 　　2 虚拟化方案 　　非标卡的虚拟化方案如下： 　　图 2 非标卡虚拟化方案 　　如图2，方案包含以下几个部分： 　　1）TUN/TAP虚拟网卡 　　运行在内核模式下。 　　2）中转程序 　　运行在用户模式下，一方面以普通文件访问接口形式与TUN/TAP虚拟网卡交互，另一方面以用户自定义的接口形式与非标卡驱动交互。 　　3）非标卡驱动 　　运行在内核模式下，为中转程序提供访问非标卡的接口。 　　4）非标卡 　　方案中的硬件部分，实际中可以是任意形式的通信卡。 　　3 应用实例 　　下面以一个实例介绍非标卡虚拟化为TAP设备的过程。 　　3.1 开发环境 　　硬件平台：CPCI工控机（X86）； 　　软件平台：Fedora 14（Linux），集成有GCC 、TUN/TAP驱动模块； 　　非标卡：6U CPCI专用卡，每块卡提供4个端口。 　　3.2 准备工作 　　1）非标卡驱动（gec.ko） 　　用于提供用户模式下应用程序访问非标卡所使用的IOCTL接口，完成读写操作，对应IOCTL CODE分别定义为IOCTL_NTM_READ、IOCTL_NTM_WRITE。在Linux用户模式下，通过对ioctl函数接口的调用，与驱动模块进行数据交互。 　　2）中转程序 　　由于中转程序要一直值守，因此选择线程方式来实现。一个线程负责调用read从TAP接收数据，进行处理，通过ioctl将数据传给非标卡驱动，发送出去；另一线程负责调用ioctl从非标卡驱动接收来自非标卡的数据包，经处理，调用write传递给TAP。 　　3.3 虚拟化过程 　　1）驱动加载 　　insmod gec.ko 　　移除用rmmod，查看当前加载进内核的模块用lsmod。 　　2）对非标卡各个端口进行初始化，这里涉及到通过ioctl与驱动模块进行交互。