IP报文可以看作一个包
Linux网卡驱动程序，将IP包添加14字节的MAC包头，构成MAC包。
MAC包中含有发送端和接收端的MAC地址信息。既然是驱动程序创建的MAC包头信息，当然可以随便输入地址信息的，主机伪装就是这么实现的。
驱动程序将MAC包拷贝到网卡芯片内部的缓存区，就算完事了。有网卡芯片接手处理。网卡芯片对MAC包，再次封装成物理帧，添加头部同步信息和CRC校验。然后丢到网线上，就完成一个IP报文的发送。所有挂接到本网线的网卡都可以看到该物理帧。
网卡如何接收数据包
正常情况：
网线上的物理帧首先被网卡芯片获取，网卡芯片会检查物理帧的CRC，保证完整性。其次，网卡芯片将物理帧头去掉，得到MAC包。
网卡芯片检查MAC包内的目的MAC地址信息，和本网卡的MAC地址是否一致？不一致，抛弃。
网卡芯片将MAC帧拷贝到网卡的内部缓冲区，触发中断。
驱动程序通过中断，将MAC包拷贝到系统中，构建sk_buff。告诉上层。
上层去掉MAC包头，得到需要的IP包。
过程中，网卡芯片对物理帧进行了MAC匹配过滤。这样做可以减小系统负荷。试想一下，若网卡芯片对所有的MAC帧不加判断的直接提供给驱动，让CPU判决会是什么样子呢？当总线上数据繁忙，CPU将浪费大部分时间去判断该MAC包是否是自己需要的，效率低下。
不正常模式（混听）：
网线上的物理帧首先被网卡芯片获取，网卡芯片会检查物理帧的CRC，保证完整性。其次，网卡芯片将物理帧头去掉，得到MAC包。网卡芯片发现自己当前被配置为混听模式，就不对MAC包过滤。网卡芯片将MAC帧拷贝到网卡内部的缓冲区，触发中断。驱动程序通过中断，
将MAC包拷贝到系统中，构建sk_buff，告诉上层。上层去掉MAC包头，得到需要的IP包。显然，这里的IP包并不一定是发给自己的。
驱动的问题：
网卡到底能不能接收其他MAC包，完全取决于网卡芯片中RCR( receive control register )配置。驱动程序是决定网卡能否工作于混听模式的桥梁。混听模式会加重CPU的负荷，而且也是不符合标准应用的！
