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的负荷，而且也是不符合标准应用的！

 

    所有的车辆都要从加油站穿过，（有些都不加油），加油站工作人员的任务量就可想而知。

    当然也有例外，有些程序不通过驱动，也可以直接访问网卡芯片RCR达到设置混听模式。

    所谓 条条大路通香港，就是这个道理：）没有绝对的。