数据包接收系列 — 上半部实现(网卡驱动)

格式：pdf
大小：142.29 KB
文档页数：5

下载文档原格式

Linux网卡设备驱动程序设计（3）

网络错误503请刷新页面重试持续报错请尝试更换浏览器或网络环境
Linux网卡设备驱动程序设计（ 3）
三。网络子系统深度分析用户程序通过网络发送这个网络数据包通过 SCI 协议无关接口协议栈《 UDP的实现会选择路由《 IP的实现会建立这个邻居子系统，建立邻居信息设备无关接口驱动函数调用关系（对应上面） socket_file_ops do_sock_write _sock_sendmsg (SCI 接口) udp_sendmsg(路由ip_route_output_flow) udp_push_pending_frames (选择路由) ip_push_penging_frames ip_local_out(实现防火墙) dst_output ip_finish_output ip_finish_output2(dev->neighbour->output) // 邻居子系统 arp_generic_ops->neigh_resolve_output (建立邻居子系统) dev_queue_xmit dev_hard_start_xmit （协议无关接口） dev->netdev_ops->ndo_start_xmit （驱动） 2.网卡收到数据包如何交给用户来处理收到函数Receive（）
会产生一个中断 1. 接受 (1). 从硬件中读取数据到SKB中 (2).调用Netif_rx()函数
பைடு நூலகம் 2.

嵌入式Linux虚拟网卡驱动中数据包的提取及转发技术

嵌入式Linux虚拟网卡驱动中数据包的提取及转发技术曹志龙;郑日荣【期刊名称】《工业控制计算机》【年(卷),期】2015(0)5【摘要】This paper introduces a method which can write virtual network card drive program with Linux system,and extracts the data packets from it,then handle packets according to the pre-arranged rule,at last sent the data packet by Linux kernel socket.Through this technology,people can reach the goal of dealing with and forwarding the data packets which fetched in virtual network card drive.%网络设备是完成用户数据包在网络媒介上发送和接收的设备，它将上层协议传递下来的数据包以特定的媒介访问控制方式进行发送，并将接收到的数据传递给上层协议。

提出了一种在Linux系统下编写虚拟网卡驱动程序，并在虚拟网卡驱动中提取出数据包，再根据事先约定好的规则对数据包做处理，最后通过Linux内核socket机制将数据包发送出去的技术。

在工程项目中，采用此种技术，可以实现在虚拟网卡驱动中抓取出数据包，然后根据具体要求处理及转发数据包。

【总页数】2页(P31-32)【作者】曹志龙;郑日荣【作者单位】广东工业大学自动化学院，广东广州 510006;广东工业大学自动化学院，广东广州 510006【正文语种】中文【相关文献】1.基于ARM的数据包提取转发机制的研究 [J], 张功萱;王平立;何广生;张冲2.基于嵌入式Linux的以太网卡驱动设计与实现 [J], 龙新辉;陈俊杰3.嵌入式Linux的USB Chirp无线网卡驱动设计 [J], 叶学程;郑霖4.嵌入式linux下DM9000网卡驱动的移植与实现 [J], 贺金平5.基于嵌入式linux的无线网卡驱动程序 [J], 钱晓华;郭继红因版权原因，仅展示原文概要，查看原文内容请购买。

在linux系统下如何安装网卡驱动

2011年研发二部工作周报月报作者：***时间：2012-6-13目录一、整理漏扫系统的结构 (1)1、整理NetScan目录中的程序。

(1)2、整理proftpd目录中内容（插件的检测信息）。

(4)3、整理proxyd目录中的安管（安管平台）。

(8)二、熟悉Nessus的工作原理 (8)1、Nessus扫描引擎的工作原理.... 错误!未定义书签。

三、整理运行的整个流程............... 错误!未定义书签。

1、通过客户端下发策略，上传到服务器上。

错误!未定义书签。

2、服务端：接收客户端下发的策略。

错误!未定义书签。

3、服务端进行身份的认证........ 错误!未定义书签。

一、整理漏扫系统的结构网卡是Linux服务器中最重要网络设备。

据统计，Linux网络故障有35％在物理层、25％在数据链路层、10％在网络层、10％在传输层、10％在对话、7％在表示层、3％在应用层。

由此可以看出，网络故障通常发生在网络七层模型的下三层，即物理层、链路层和网络层。

对应于实际网络也就是使用的网络线缆、网卡、交换机、路由器等设备故障。

Linux的网络实现是模仿FreeBSD的，它支持FreeBSD 的带有扩展的Sockets（套接字）和TCP/IP协议。

它支持两个主机间的网络连接和Sockets通讯模型，实现了两种类型的Sockets：BSD Sockets和INET Sockets。

它为不同的通信模型和服务质量提供了两种传输协议，即不可靠的、基于消息的UDP传输协议和可靠的、基于流的传输协议TCP，并且都是在IP网络协议上实现的。

INET sockets 是在以上两个协议及IP协议之上实现的。

由于交换机、路由器通常独立于Linux或者其他操作系统。

网卡设置故障是造成Linux 服务器故障最主要原因。

可能因为硬件的质量或性能、磨损老化、人为误操作、不正确的网络设置、管理问题、Linux软件的BUG、系统受到黑客攻击和Linux病毒等原因造成。

Python选择网卡发包及接收数据包

Python选择⽹卡发包及接收数据包当⼀台计算机上有多个⽹卡时，需要选择对应IP地址的⽹卡进⾏发送数据包或者接受数据包。

1、选择⽹卡发包（应⽤scapy）：plface=conf.route.route("××.××.××.××")[0]#××.××.××.××为对应⽹卡⽹络中存在设备的IP地址。

不能是需要发送数据包的⽹卡的IP地址（会报“result too large”）pkt=conf.L2socket(plface)pack_ip,pack_udp,pack_ether=self.udp_pack()t= str(pack_ether/pack_ip/pack_udp/udp_packdata)udp_pack = Ether(t)pkt.send(udp_pack)2、选择⽹卡进⾏包的接收1）如下⽅法，只能获得⼀个⽹卡的ip地址（选择哪个⽹卡，优先级未知）socket.getaddrinfo(socket.gethostname(),None)[-1][4][0]2）如下⽅法，可根据ip地址确定⽹卡：HOST = socket.gethostbyname(socket.gethostname())s=socket.socket(socket.AF_INET,socket.SOCK_RAW,socket.IPPROTO_IP)s.bind((HOST,0))host可以直接⽤⽹卡ip地址代替，这样就可以选择⽹卡进⾏包的接受了总结以上就是这篇⽂章的全部内容了，希望本⽂的内容对⼤家的学习或者⼯作具有⼀定的参考学习价值，谢谢⼤家对的⽀持。

如果你想了解更多相关内容请查看下⾯相关链接。

Linux网卡驱动架构分析

Linux⽹卡驱动架构分析⼀、⽹卡驱动架构由上到下层次依次为：应⽤程序→系统调⽤接⼝→协议⽆关接⼝→⽹络协议栈→设备⽆关接⼝→设备驱动。

⼆、重要数据结构 1、Linux内核中每⼀个⽹卡由⼀个net_device结构来描述。

2、⽹卡操作函数集：net_device_ops，这个数据结构是上⾯net_device的⼀个成员。

3、⽹络数据包：sk_buff。

三、⽹卡驱动代码分析所⽤⽂件为cs89x0.c，主要分析三个部分：⽹卡初始化、发送数据、接收数据。

㈠⽹卡初始化⽹卡驱动初始化主要在函数init_module中完成，部分代码如下：int __init init_module(void){ struct net_device *dev = alloc_etherdev(sizeof(struct net_local)); struct net_local *lp; int ret = 0; ... dev->irq = irq; dev->base_addr = io; ... ret = cs89x0_probe1(dev, io, 1); ...} cs89x0_probe1函数部分代码如下：static int __init cs89x0_probe1(struct net_device *dev, int ioaddr, int modular){ struct net_local *lp = netdev_priv(dev); static unsigned version_printed; int i; int tmp; unsigned rev_type = 0; int eeprom_buff[CHKSUM_LEN]; int retval; ... writeword(ioaddr, ADD_PORT, PP_ChipID); tmp = readword(ioaddr, DATA_PORT); //对硬件的初始化 ... for (i = 0; i < ETH_ALEN/2; i++) //初始化MAC地址 { dev->dev_addr[i*2] = eeprom_buff[i]; dev->dev_addr[i*2+1] = eeprom_buff[i] >> 8; } ... dev->netdev_ops = &net_ops; //初始化netdev_ops ... retval = register_netdev(dev); //注册⽹卡驱动} 由代码可以看出 1、定义并分配net_device结构，使⽤alloc_etherdev函数。

可运行在单片机上的UDP通讯协议的实现

简单解释一下上面三个过程。初始化不用解释了。A R P 通讯是整个网络传输的开始，而且只需要运行一次。在《单片机驱动 D M 9 0 0 0 网卡芯片（详细调试过程）【下】》最后的部分已经讲清楚了。主要是解释第三条，u d p 通讯收发数据。 O S I 参考模型中 a r p 协议属于链路层（最底层），i p 协议比 a r p 协议高一层属于网络层（这一层还包括 i c m p 和i g m p 协议），在往上一层是运输层，包括 t c p 协议和 u d p 协议。但是按我的理解，从数据包格式的角度看，我把 a r p 协议与 i p 协议放在同一级别，我们接收到的数据包中的前几十个字节用来判断是 a r p 协议还是 i p 协议，也就是说这两个协议是互补相容的（下面程序中会做个过滤，数据包只接收 a r p 或i p 协议，最后处理的数据包中只能是 a r p 协议或者是 i p 协议）。这种互补相容的协议同样也适用于 t c p 协议和 u d p 协议上。既然有互不相容的协议，那么也就有相容的协议了，这种相容的协议就是指一个协议必须依赖于另一种协议才能实就像一件外套，u d p 协议好比一件衬衫，而真正的数据可以看做是穿衣服的人。穿衣服的人先穿上衬衫再穿外套，这两个协议之间的关系就是这样： u d p 协议将数据包起来，i p 协议又将 u d p 协议连同其中的数据一起包起来。也就是说，实际的数据经过 u d p 协议的包装，在经过 i p 协议的包装之后才能发送出去。虽然看起来有些繁琐，但实际计算机端就是这样识别数据的。所谓的包装就是在被包装数据前加上一小段首部数据，一般几十个字节左右。 2 、A R P 协议的实现这部分内容在《单片机驱动 D M 9 0 0 0 网卡芯片（详细调试过程）【下】》的后半部分已经讲过，这里为了完整性再重复一次。在写所有协议之前，有些全局变量需要事先设定一下，如 i p 地址、m a c 地址等信息。另外，统一规定一下我们的单片机系统为“基板”，计算机端为“上位机”，以下叫起来方便。再规定一下：c h a r 型是 8 位，s h o r t 型是 1 6 位，l o n g 型是 3 2 位。O K ！ / * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * / u n s i g n e dc h a rm y _ m a c a d d r [ 6 ]={0 x 0 0 ,0 x 0 a ,0 x 0 0 ,0 x 0 1 ,0 x 0 2 ,0 x 0 3} ; / / 基板上 m a c 地址，这里随便写 6 个字节。 u n s i g n e dc h a rm y _ i p a d d r [ 4 ]={1 9 2 ,1 6 8 ,1 ,2 0 7} ; / / 基板上 i p 地址，根据网关写入合适值。 u n s i g n e dc h a rs e r v e r _ m a c a d d r [ 6 ]={0 x f f ,0 x f f ,0 x f f ,0 x f f ,0 x f f ,0 x f f} ; / / 上位机 m a c 地址，通过 a r p 协议获取后改变。 u n s i g n e dc h a rs e r v e r _ i p a d d r [ 4 ]={ 1 9 2 ,1 6 8 ,1 ,1 2 2 } ; / / 上位机 i p 地址，看自己的电脑，这个应该会，不会就问问旁边的人吧。 u n s i g n e dc h a rt r a n s m i t _ b u f f e r [ 2 0 4 8 ]={0} ; / / 发送数据包缓存区 u n s i g n e dc h a rr e c e i v e _ b u f f e r [ 2 0 4 8 ]={0} ; / / 接收数据包缓存区 / * 如果为了节省 r a m ，这两个区可以共用一个（因为发送和接收数据可以分开进行，而且一般网卡芯片内部都会有自己独立的接收和发送缓存的），容量也可以改小，写成“u n s i g n e dc h a r d a t a _ b u f f e r [ 1 0 0 0 ]={0} ; ”我的 r a m 比较多，所以用了两个区，而且占用很大空间。* /

网络数据包收发流程1

网络数据包收发流程(1)：从驱动到协议栈2013-06-26 14:47:19标签：控制器数据包以太网网络流量原文出处：/uid-24148050-id-464587.html一、硬件环境intel82546：PHY与MAC集成在一起的PCI网卡芯片，很强大bcm5461：PHY芯片，与之对应的MAC是TSECTSEC：Three Speed Ethernet Controller，三速以太网控制器，PowerPc 架构CPU里面的MAC 模块注意,TSEC内部有DMA子模块话说现在的CPU越来越牛叉了，什么功能都往里面加，最常见的如MAC功能。

TSEC只是MAC功能模块的一种，其他架构的cpu也有和TSEC类似的MAC功能模块。

这些集成到CPU芯片上的功能模块有个学名，叫平台设备，即platform device。

二、网络收包原理网络驱动收包大致有3种情况：no NAPI：mac每收到一个以太网包，都会产生一个接收中断给cpu，即完全靠中断方式来收包缺点是当网络流量很大时，cpu大部分时间都耗在了处理mac的中断。

netpoll：在网络和I/O子系统尚不能完整可用时，模拟了来自指定设备的中断，即轮询收包。

缺点是实时性差NAPI：采用中断+ 轮询的方式：mac收到一个包来后会产生接收中断，但是马上关闭。

直到收够了netdev_max_backlog个包（默认300），或者收完mac上所有包后，才再打开接收中断通过sysctl来修改dev_max_backlog或者通过proc修改/proc/sys/net/core/netdev_max_backlog下面只写内核配置成使用NAPI的情况，只写TSEC驱动。

（非NAPI的情况和PCI网卡驱动以后再说）内核版本linux 2.6.24三、NAPI 相关数据结构每个网络设备（MAC层）都有自己的net_device数据结构，这个结构上有napi_struct。

Linux内核数据包处理流程

/*
*定义一个名为e100_driver的PCI设备
* 1、设备的探测函数为e100_probe;
* 2、设备的id_table表为e100_id_table
*/
static struct pci_driver e100_driver = {
.name = DRV_NAME,
.id_table = e100_id_table,
if (!request_region(pci_resource_start(pdev, bar),
pci_resource_len(pdev, bar), res_name))
goto err_out;
}
else if (pci_resource_flags(pdev, bar) & IORESOURCE_MEM) {
void (*shutdown) (struct pci_dev *dev);
struct device_driver driver;
struct pci_dynids dynids;
};
因为在系统引导的时候，PCI设备已经被识别，当内核发现一个已经检测到的设备同驱动注册的id_table中的信息相匹配时，它就会触发驱动的probe函数，以e100为例：
printk(KERN_INFO PFX "%s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
printk(KERN_INFO PFX "%s\n", DRV_COPYRIGHT);
}
return pci_module_init(&e100_driver);
}
一切顺利的话，注册的e100_probe函数将被内核调用，这个函数完成两个重要的工作：

网络通信技术与故障排除指南

网络通信技术与故障排除指南第1章网络通信基础 (4)1.1 网络通信原理 (4)1.1.1 通信模型 (4)1.1.2 数据封装与解封装 (4)1.1.3 数据传输方式 (4)1.2 网络协议与标准 (4)1.2.1 TCP/IP协议族 (4)1.2.2 常用网络协议 (5)1.2.3 网络标准组织 (5)1.3 网络设备与布线 (5)1.3.1 网络设备 (5)1.3.2 布线技术 (5)1.3.3 网络拓扑结构 (5)第2章传输介质与接口技术 (5)2.1 有线传输介质 (5)2.1.1 双绞线 (6)2.1.2 同轴电缆 (6)2.1.3 光纤 (6)2.1.4 电力线通信 (6)2.2 无线传输介质 (6)2.2.1 无线局域网 (6)2.2.2 蓝牙 (6)2.2.3 无线广域网 (6)2.2.4 卫星通信 (7)2.3 网络接口卡与驱动程序 (7)2.3.1 网络接口卡 (7)2.3.2 驱动程序 (7)2.3.3 网络接口卡与驱动程序的故障排除 (7)第3章 IP地址与子网划分 (7)3.1 IP地址基础知识 (7)3.1.1 IP地址的格式与表示 (7)3.1.2 IP地址类型 (7)3.1.3 IP地址分配 (7)3.2 子网划分与VLSM (8)3.2.1 子网划分的基础知识 (8)3.2.2 子网掩码 (8)3.2.3 VLSM的应用 (8)3.3 公私网地址与NAT技术 (8)3.3.1 公私网地址 (8)3.3.2 私网地址范围 (8)10.0.0.0 ~ 10.255.255.255 (8)172.16.0.0 ~ 172.31.255.255 (8)192.168.0.0 ~ 192.168.255.255 (8)3.3.3 NAT技术 (8)第4章路由与交换技术 (9)4.1 路由原理与路由器配置 (9)4.1.1 路由基本概念 (9)4.1.2 路由器工作原理 (9)4.1.3 路由器配置方法 (9)4.1.4 路由器故障排除 (9)4.2 交换原理与交换机配置 (9)4.2.1 交换基本概念 (9)4.2.2 交换机工作原理 (9)4.2.3 交换机配置方法 (9)4.2.4 交换机故障排除 (9)4.3 路由协议与网络收敛 (10)4.3.1 路由协议概述 (10)4.3.2 常见路由协议 (10)4.3.3 网络收敛 (10)4.3.4 路由协议故障排除 (10)第5章网络安全策略 (10)5.1 防火墙配置与管理 (10)5.1.1 防火墙概述 (10)5.1.2 防火墙类型及选择 (10)5.1.3 防火墙配置方法 (10)5.1.4 防火墙管理策略 (10)5.2 VPN技术与应用 (11)5.2.1 VPN概述 (11)5.2.2 VPN关键技术 (11)5.2.3 VPN配置与应用 (11)5.3 入侵检测与防护系统 (11)5.3.1 入侵检测系统概述 (11)5.3.2 入侵防护系统 (11)5.3.3 入侵检测与防护系统配置与管理 (11)5.3.4 入侵检测与防护系统应用实践 (11)第6章常见网络故障排除方法 (11)6.1 故障排除流程与技巧 (11)6.1.1 故障排除的基本流程 (11)6.1.2 故障排除的技巧 (12)6.2 网络诊断工具与命令 (12)6.2.1 常用网络诊断工具 (12)6.2.2 常用网络诊断命令 (12)6.3 网络功能分析与优化 (12)6.3.1 网络功能分析 (12)6.3.2 网络优化措施 (13)第7章局域网故障排除 (13)7.1 拓扑结构与VLAN问题 (13)7.1.1 拓扑结构问题 (13)7.1.1.1 拓扑结构错误识别 (13)7.1.1.2 网络环路处理 (13)7.1.2 VLAN问题 (13)7.1.2.1 VLAN配置错误 (13)7.1.2.2 VLAN间路由问题 (13)7.2 交换机故障分析与处理 (14)7.2.1 交换机硬件故障 (14)7.2.2 交换机软件故障 (14)7.2.3 交换机功能问题 (14)7.3 无线网络故障分析与处理 (14)7.3.1 无线信号覆盖问题 (14)7.3.2 无线认证故障 (14)7.3.3 无线网络功能问题 (14)第8章广域网故障排除 (14)8.1 路由器故障分析与处理 (14)8.1.1 故障现象及原因 (14)8.1.2 故障排除方法 (15)8.2 公网连接与运营商问题 (15)8.2.1 故障现象及原因 (15)8.2.2 故障排除方法 (15)8.3 VPN故障分析与处理 (16)8.3.1 故障现象及原因 (16)8.3.2 故障排除方法 (16)第9章网络服务故障排除 (17)9.1 DNS服务故障分析与处理 (17)9.1.1 故障现象 (17)9.1.2 故障原因 (17)9.1.3 故障排除方法 (17)9.2 DHCP服务故障分析与处理 (17)9.2.1 故障现象 (17)9.2.2 故障原因 (17)9.2.3 故障排除方法 (17)9.3 邮件服务器故障分析与处理 (18)9.3.1 故障现象 (18)9.3.2 故障原因 (18)9.3.3 故障排除方法 (18)第10章网络安全事件处理 (18)10.1 安全事件分析与应急响应 (18)10.1.1 安全事件分类 (18)10.1.2 安全事件分析 (18)10.1.3 应急响应流程 (18)10.1.4 应急响应团队建设 (19)10.2 恶意软件与病毒防护 (19)10.2.1 恶意软件分类 (19)10.2.2 病毒防护策略 (19)10.2.3 恶意软件防护技术 (19)10.2.4 恶意软件防范意识 (19)10.3 数据泄露与防护措施 (19)10.3.1 数据泄露途径 (19)10.3.2 数据泄露防护策略 (19)10.3.3 数据泄露防护技术 (19)10.3.4 数据泄露应对措施 (20)第1章网络通信基础1.1 网络通信原理网络通信是现代信息技术的基础，它通过一系列的通信协议和设备实现数据在不同计算机之间的传输。

windowsnt环境下fddi网卡驱动程序设计(2)

windowsnt环境下fddi网卡驱动程序设计（2）【摘要】本文介绍了在Windows NT环境下设计FDDI网卡驱动程序的相关内容。

在先概述了本文要讨论的内容，然后介绍了研究背景。

在分别讨论了驱动程序框架设计、硬件抽象层设计、设备管理器设计、中断处理设计和数据传输设计。

通过这些设计，可以有效地实现FDDI网卡在Windows NT环境下的驱动程序功能。

在结论部分总结了本文的主要内容，展望了未来可能的研究方向。

本文的设计和讨论为开发者提供了实用的指导，帮助他们更好地理解和应用FDDI网卡驱动程序设计。

【关键词】关键词：Windows NT、FDDI网卡、驱动程序设计、框架设计、硬件抽象层、设备管理器、中断处理、数据传输、总结、展望未来。

1. 引言1.1 概述Windows NT环境下FDDI网卡驱动程序的设计是一个重要的工作，它涉及到计算机网络领域中的硬件和软件技术。

FDDI（Fiber Distributed Data Interface）是一种用于局域网的高速传输技术，通过光纤传输数据，具有高带宽和低延迟的特点。

而在Windows NT操作系统中，网络设备的驱动程序是连接硬件设备和操作系统之间的桥梁，是实现设备功能的重要组成部分。

本文将围绕着Windows NT环境下FDDI网卡驱动程序的设计展开讨论，首先对驱动程序的框架进行设计，确定整体架构和功能模块。

然后针对硬件抽象层进行设计，实现与具体硬件设备的通信和控制。

接着对设备管理器进行设计，实现对设备的注册和管理。

同时还将探讨中断处理的设计和数据传输的设计，保证数据的高效传输和处理。

通过对Windows NT环境下FDDI网卡驱动程序的设计与实现，可以提高网络设备的性能和稳定性，同时扩展网络功能和提升用户体验。

本文的研究将为未来网络设备驱动程序设计提供参考，并为网络技术的发展做出贡献。

1.2 研究背景在当今数字化社会中，网络通信扮演着至关重要的角色。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

数据包接收系列 — 上半部实现（网卡驱动）数据包接收系列 — 上半部实现（网卡驱动）网卡概述

(1) 网卡收包

网线上的物理帧首先被网卡芯片获取，网卡芯片会检查物理帧的CRC，保证完整性。然后网卡芯片将物理帧头去掉，得到MAC包。网卡芯片会检查MAC包内的目的MAC地址，如果和本网卡的MAC地址不一样则丢弃(混杂模式除外)。之后网卡芯片将MAC帧拷贝到网卡内部的缓冲区，触发硬中断。网卡的驱动程序通过硬中断处理函数，构建sk_buff，把它拷贝到内存中，接下来交给内核处理。在这个过程中，网卡芯片对物理帧进行了MAC匹配过滤，以减小系统负荷。

(2) 网卡发包

网卡驱动程序将IP包添加14字节的MAC头，构成MAC包。MAC包中含有发送端和接收端的MAC地址，由于是驱动程序创建MAC头，所以可以随便输入地址

进行主机伪装。驱动程序将MAC包拷贝到网卡芯片内部的缓冲区，接下来由网卡芯片处理。网卡芯片将MAC包再次封装为物理帧，添加头部同步信息和CRC校验，然后丢到网线上，就完成一个IP报的发送了，所有接到网线上的网卡都可以看到该物理帧。

(3) 网卡数据结构

网卡用net_device来表示，用register_netdevice()注册到系统中，注册过的网卡可以通过unregister_netdevice()注销掉。

[java] view plain copy 1. struct net_device { 2. char name[IFNAME]; /* 网卡名称，如eth0 */ 3. ... 4. unsigned long mem_end; /* shared mem end，共享内存结束地址 */ 5. unsigned long mem_start; /* shared mem start ，共享内存起始地址 */ 6. unsigned long base_addr; /* device I/O address，设备内存映射到I/O内存的起始地址 */ 7. unsigned int irq; /* device IRQ number，硬中断编号 */ 8. ... 9. unsigned long state; /* 网卡的状态 */ 10. ... 11. struct list_head dev_list; 12. struct list_head napi_list; /* NAPI使用 */ 13. ... 14. unsigned long features; /* 网卡功能标识 */ 15. ... 16. int ifindex; /* Interface index. Unique device identifier. 设备ID */ 17. ... 18. struct net_device_stats stats; /* 统计变量 */ 19. /* dropped packets by core network. 20. * Do not use this in drivers. 21. * 被内核丢弃的数据包个数。 22. */ 23. atomic_long_t rx_dropped; 24. ... 25. /* Management operations */ 26. const struct net_device_ops *netdev_ops; /* 网卡的操作函数集 */ 27. const struct ethtool_ops *ethtool_ops; /* 配置网卡 */ 28. ... 29. unsigned int promiscuity; /* 混杂模式计数器 */ 30. ... 31. struct netdev_queue *ingress_queue; 32. struct netdev_queue *_tx; 33. ... 34. }; 35. 36. /* 网卡的操作函数集 */ 37. struct net_device_ops { 38. int (*ndo_init) (struct net_device *dev); 39. void (*ndo_uninit) (struct net_device *dev); 40. int (*ndo_open) (struct net_device *dev); 41. int (*ndo_stop) (struct net_device *dev); 42. /* Called when a packet needs to be transmitted */ 43. netdev_tx_t (*ndo_start_xmit) (struct sk_buff *skb, struct net_device *dev); 44. ... 45. };

(4) 网卡中断处理函数

产生中断的每个设备都有一个相应的中断处理程序，是设备驱动程序的一部分。每个网卡都有一个中断处理程序，用于通知网卡该中断已经被接收了，以及把网卡缓冲区的数据包拷贝到内存中。当网卡接收来自网络的数据包时，需要通知内核数据包到了。网卡立即发出中断：嗨，内核，我这里有最新的数据包了。内核通过执行网卡已注册的中断处理函数来做出应答。中断处理程序开始执行，通知硬件，拷贝最新的网络数据包到内存，然后读取网卡更多的数据包。这些都是重要、紧迫而又与硬件相关的工作。内核通常需要快速的拷贝网络数据包到系统内存，因为网卡上接收网络数据包的缓存大小固定，而且相比系统内存也要小得多。所以上述拷贝动作一旦被延迟，必然造成网卡缓存溢出 - 进入的数据包占满了网卡的缓存，后续的包只能被丢弃。当网络数据包被拷贝到系统内存后，中断的任务算是完成了，这时它把控制权交还给被系统中断前运行的程序。处理和操作数据包的其他工作在随后的下半部中进行。

上半部的实现接收数据包的上半部处理流程为：el_interrupt() // 网卡驱动

|--> el_receive() // 网卡驱动

|--> netif_rx() // 内核接口

|--> enqueue_to_backlog() // 内核接口

这里以3c501网卡驱动为例来进行分析（这是个古董级网卡，实现简单：） el_interrupt

3c501的网卡中断处理函数为el_interrupt()，调用inb()来获取当前中断处理结果，如果是RX_GOOD，

表明网卡成功接收了数据包，则调用el_receive()来进行接收处理。[java] view plain copy 1. /** 2. * el_interrupt: 3. * @irq: Interrupt number 4. * @dev_id: The 3c501 that burped 5. */ 6. 7. static irqreturn_t el_interrupt(int irq, void *dev_id) 8. { 9. struct net_device *dev = dev_id; 10. struct net_local *lp; 11. int ioaddr; 12. int axsr; /* Aux. status reg. */ 13. 14. ioaddr = dev->base_addr; /* I/O映射地址 */ 15. lp = netdev_priv(dev); /* 网卡的私有数据 */ 16. spin_lock(&lp->lock); /* 上锁 */ 17. 18. /* What happened? */ 19. axsr = inb(AX_STATUS); 20. 21. /* log it */ 22. if (el_debug > 3) 23. pr_debug("%s: el_interrupt() aux = %#02x\n", dev->name, axsr); 24. if (lp->loading == 1 && ! lp->txing) 25. pr_warning("%s: Inconsistent state loading while not in tx\n", dev->name); 26. 27. if (lp->txing) { /* 处于发送模式，这里不研究 */ 28. /* Board in transmit mode. */ 29. ... 30. 31. } else { 32. /* In receive mode. 处于接收模式 */ 33. int rxsr = inb(RX_STATUS); /* 获取中断处理的结果 */ 34. if (el_debug > 5) 35. pr_debug("%s: rxsr=%02x txsr=%02x rp=%04x\n", dev->name, rxsr, 36. inb(TX_STATUS), inw(RX_LOW)); 37. 38. /* Just reading rx_status fixes most errors. */ 39. if (rxsr & RX_MISSED) /* 没有接收到数据包 */ 40. dev->stats.rx_missed_errors++; 41. else if (rxsr & RX_RUNT) { /* 数据包长度错误 */ 42. /* Handled to avoid board lock-up. */ 43. dev->stats.rx_length_errors++; 44. if (el_debug > 5) 45. pr_debug("%s: runt.\n", dev->name); 46. 47. } else if (rxsr & RX_GOOD) { 48. /* Receive worked, 成功接收数据包 */ 49. el_receive(dev); /* 接收函数 */ 50. 51. } else { 52. /* Nothing? Something is broken! */ 53. if (el_debug > 2) 54. pr_debug("%s: No packet seen, rxsr=%02x **resetting 3c501***\n", dev->name, rxsr); 55. 56. el_reset(dev); /* 网卡出错，重置 */ 57. } 58. } 59. 60. /* Move into receive mode */ 61. outb(AX_RX, AX_CMD); 62. outw(0x00, RX_BUF_CLR); 63. inb(RX_STATUS); 64. inb(TX_STATUS); 65. spin_unlock(&lp->lock); 66. out: 67. return IRQ_HANDLED; 68. }