为什么我收到的packet非的启动sniffer才能接收正常啊？asmsys 和zxcasd请进，我送分来了:)其他人也进来坐坐吧！ 胡老大有没时间啊：）

老问题解决了，新问题又来了 :(
老问题见http://www.driverdevelop.com/forum/html_65893.html?1082699550

具体如下：
我在miniport（虚拟的）中的miniportsend例程中把收到的packet数据取到自己的缓冲区，然后修改目的和源MAC,ip地址信息，端口，校验和等信息，再回传到上层协议，用sniffer可以抓到发送和接收到的包，应用程序也可收到包。但只要关闭sniffer就完蛋啦！应用程序就收不到包啦。

具体方案和现象如下：我实现的是虚拟网卡，就是没有硬件的，现在再测试收发功能，本来收发要靠irp请求的。

　　安装两个网卡（为同样的虚拟网卡），设置通网段ip地址，简称a和b.现在通过a发udp包到一个不存在的c地址。在miniport做好arp欺骗(这样做是因为直接发到b会通过协议栈就转发了不经过miniport)，发送数据时，a首先发到c一个arp请求包，在miniport中收到后改为c到b的ARP请求包上指到协议栈，这时会有个b到c应答ARP包，在miniport中收到后改为c到a的应答包，这样a和b就都有了c的mac地址，做好了ARP准备后开始发包。数据包的转发同ARP包。

/*****************************************************
    其实现在的问题（可能）就是为什么在b收到ARP请求包后，没有ARP应答包？我DbgPrint出来的没有ARP应答包的：（，用ARP -a可以看出b已经知道了c的MAC地址啊！
    而启动EtherDetect Packet Sniffer绑定b时ARP应答包就有了，并且正确。
    郁闷啊！这好像和Miniport没关系？？？？？？？？
    2004/04/26
******************************************************/

    不启动sniffer的话或者启动一个的话，发现只有b知道c的mac地址，a不知道，所以一直在发ARP请求包，用DbgPrint打印信息竟然没有ARP应答包。然后启动两个sniffer分别绑定两个网卡的话，数据的收发正常（即应用层可以收发数据，数据流经miniport）。但是如果停止发送网卡的sniffer的话，一切还是正常。只要停止绑定接收网卡的sniffer就收就停止，启动抓包，接受就又正常。
    我被搞晕了，各位费心帮帮忙吧！以下是相关源代码：


[编辑 -  4/26/04 by  flyhobo]

//****************************
pTCB->pData为接收到mac包缓冲区

a的ip地址为172.96.38.85（85 = 0x55）
b的ip地址为172.96.38.88（88 = 0x58）
c的ip地址为172.96.38.86（86 = 0x56） mac = 02-50-f2-00-00-88
//****************************

DbgPrint(\"当前版本号:206\\n\");
pChar = pTCB->pData;
if ((pChar[12] == 0x08) && (pChar[13] == 0x06))
{
DbgPrint(\"当前包为ARP包：\");

#if DBG
ARPPacketView(pChar);//dbgprint察看整个ARp包
#endif

//if this is a query ARP
if ((pChar[20] == 0x00) && (pChar[21] == 0x01))
{
//if from 55 to 56
if ((pChar[31] == 0x55) && (pChar[41] == 0x56))
{
//chang ARP to that form 56 to 58
MACAddr_IP55.Add[0] = pChar[6];
MACAddr_IP55.Add[1] = pChar[7];
MACAddr_IP55.Add[2] = pChar[8];
MACAddr_IP55.Add[3] = pChar[9];
MACAddr_IP55.Add[4] = pChar[10];
MACAddr_IP55.Add[5] = pChar[11];

pChar[6] = MACAddr_IP56.Add[0];
pChar[7] = MACAddr_IP56.Add[1];
pChar[8] = MACAddr_IP56.Add[2];
pChar[9] = MACAddr_IP56.Add[3];
pChar[10] = MACAddr_IP56.Add[4];
pChar[11] = MACAddr_IP56.Add[5];

pChar[22] = MACAddr_IP56.Add[0];
pChar[23] = MACAddr_IP56.Add[1];
pChar[24] = MACAddr_IP56.Add[2];
pChar[25] = MACAddr_IP56.Add[3];
pChar[26] = MACAddr_IP56.Add[4];
pChar[27] = MACAddr_IP56.Add[5];

pChar[31] = 0x56;
pChar[41] = 0x58;

DbgPrint(\"Message：当前ARP query包已处理\");
#if DBG
ARPPacketView(pChar);
#endif
}
else
{
DbgPrint(\"Warning：当前ARP query包为非预测包,不予处理\");
}
}
//else if this is a answer ARP
else if ((pChar[20] == 0x00) && (pChar[21] == 0x02))
{
//if from 58 to 56
if ((pChar[31] == 0x58) && (pChar[41] == 0x56))
{
//chang ARP to that form 56 to 55
pChar[0] = MACAddr_IP55.Add[0];
pChar[1] = MACAddr_IP55.Add[1];
pChar[2] = MACAddr_IP55.Add[2];
pChar[3] = MACAddr_IP55.Add[3];
pChar[4] = MACAddr_IP55.Add[4];
pChar[5] = MACAddr_IP55.Add[5];

MACAddr_IP58.Add[0] = pChar[6];
MACAddr_IP58.Add[1] = pChar[7];
MACAddr_IP58.Add[2] = pChar[8];
MACAddr_IP58.Add[3] = pChar[9];
MACAddr_IP58.Add[4] = pChar[10];
MACAddr_IP58.Add[5] = pChar[11];

pChar[6] = MACAddr_IP56.Add[0];
pChar[7] = MACAddr_IP56.Add[1];
pChar[8] = MACAddr_IP56.Add[2];
pChar[9] = MACAddr_IP56.Add[3];
pChar[10] = MACAddr_IP56.Add[4];
pChar[11] = MACAddr_IP56.Add[5];

pChar[22] = MACAddr_IP56.Add[0];
pChar[23] = MACAddr_IP56.Add[1];
pChar[24] = MACAddr_IP56.Add[2];
pChar[25] = MACAddr_IP56.Add[3];
pChar[26] = MACAddr_IP56.Add[4];
pChar[27] = MACAddr_IP56.Add[5];

pChar[31] = 0x56;

pChar[32] = MACAddr_IP55.Add[0];
pChar[33] = MACAddr_IP55.Add[1];
pChar[34] = MACAddr_IP55.Add[2];
pChar[35] = MACAddr_IP55.Add[3];
pChar[36] = MACAddr_IP55.Add[4];
pChar[37] = MACAddr_IP55.Add[5];

pChar[41] = 0x55;

DbgPrint(\"Message：当前ARP answer包已处理\");
#if DBG
ARPPacketView(pChar);
#endif
}
else
{
DbgPrint(\"Warning：当前ARP answer包为非预测包,不予处理\");
}
}
}
else //为数据包
{
//if from 55 to 56
if ((pChar[29] == 0x55)&& (pChar[33] == 0x56))
{
//change from 56 to 58
DbgPrint(\"当前包为发送的数据IP包from 55 to 56：\");
DbgPrint(\"+++++++++++++++++++++++++!\");
DbgPrint(\"Modified MAC IP UDP heard!\");
DbgPrint(\"+++++++++++++++++++++++++!\");

//目的MAC地址
pChar[0] = MACAddr_IP58.Add[0];
pChar[1] = MACAddr_IP58.Add[1];
pChar[2] = MACAddr_IP58.Add[2];
pChar[3] = MACAddr_IP58.Add[3];
pChar[4] = MACAddr_IP58.Add[4];
pChar[5] = MACAddr_IP58.Add[5];

//原MAC地址
pChar[6] = MACAddr_IP56.Add[0];
pChar[7] = MACAddr_IP56.Add[1];
pChar[8] = MACAddr_IP56.Add[2];
pChar[9] = MACAddr_IP56.Add[3];
pChar[10] = MACAddr_IP56.Add[4];
pChar[11] = MACAddr_IP56.Add[5];

//源ip
pChar[29] = 0x56;

                                //目的ip
pChar[33] = 0x58;

//计算IP和UDP包头的校验和
*((unsigned short *)(pChar + 24)) = 0;
*((unsigned short *)(pChar + 24)) = cal_chksum((unsigned short *)(pChar + 14),20);

UdpCheckSum(pChar + 14);

//++++++++++++++++++++++++++++++++++++++++++
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
}
else
{
DbgPrint(\"还有其他帧类型的MAC包：\");
}
}

偶其实也不是很清楚，看了一下你的问题，我大致理解会不会是你的网卡绑定的问题，你用的sniffer是基于什么原理做的？

很可能是绑定的问题，我怀疑你虚拟网卡没有处理或没有很好的处理PNP，导致SNIFFER写载时不能被上层的PROTOCOL绑定。

很可能是绑定的问题，我怀疑你虚拟网卡没有处理或没有很好的处理PNP，导致SNIFFER写载时不能被上层的PROTOCOL绑定。

我这是虚拟网卡啊！并且系统启动时网卡也应该启动了吧？这是不启动sniffer，ARP请求包发送和接收都正常，应为通过ARP -a可以查看到b已经知道了c的mac地址，说明修改后的ARP请求包还是到达了c的。但奇怪的是没有ARP应答包，这是咋回事呢？

处理PNP，我还得看看资料了！我是在2003ddk的虚拟网卡例子NetVMini的基础上修改的，没看到他处理PNP，需要处理吗？指点一下方向和ddk中资料的位置了，我先找找。

[编辑 -  4/23/04 by  flyhobo]

偶其实也不是很清楚，看了一下你的问题，我大致理解会不会是你的网卡绑定的问题，你用的sniffer是基于什么原理做的？

>>>你用的sniffer是基于什么原理做的？
惭愧啊！我不清楚的，我用的是EtherDetect Packet Sniffer啦，好像是Politecnico di Torino的产品，看其帮助文档说“Capture IP packets on your LAN with nearly no packets losing. ”应该是工作在IP层的，事实上我也没抓到过ARP包。

[编辑 -  4/26/04 by  flyhobo]

因为SNIFFER的启动写载会改变原来的绑定关系，如果你的驱动不处理
PNP，就不能做一些动态加载的工作，来恢复到SNIFFER加载以前的状态。
关于PNP，任何将2000驱动的书上估计都有。能发一个你的程序我看看吗？

留下你的Email了 :P

因为SNIFFER的启动写载会改变原来的绑定关系，如果你的驱动不处理
PNP，就不能做一些动态加载的工作，来恢复到SNIFFER加载以前的状态。
关于PNP，任何将2000驱动的书上估计都有。能发一个你的程序我看看吗？

 :D看来我还有太多的东西要搞清楚！努力学习，天天向上！！！！

asmsys@163.com

高手那！
辛苦了，帮俺把把脉啊！俺也好有个方向
我正按asmsys的指点在啃ddk的pnp资料
但我还是担心有其他的遗漏，因为在完全不启动EtherDetect Packet Sniffer时也工作不正常，关键是必须启动EtherDetect Packet Sniffer才可以工作正常。

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
最奇怪为什么ARP请求包收发都正常，而没有ARP应答包内？
这里肯定有问题？收到ARP请求包不回应 ？？？？？？？？
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

停止EtherDetect Packet Sniffer后，数据接收停止，按 asmsys的说法可以这样理解。因为俺确实没有处理PNP，SNIFFER卸载时不能被上层的PROTOCOL绑定了。

我顶

你把A和B的IP设置为不同的网段，这样就不用做ARP欺骗了，然后再按照你上面的步骤试一下。

你把A和B的IP设置为不同的网段，这样就不用做ARP欺骗了，然后再按照你上面的步骤试一下。

我做了实验，但好像不行的，还是要做ARP欺骗的，也就是说还的要第三方的那个c来中转，并且这样一来，还得手工加route。

现在就是为什么在b收到ARP请求包却不发出ARP应答包。我感觉有可能是协议(ARP)和网卡b没有绑定好或者从别的地方走了？

最最恼火的是为什么要做这些没有太大意义的测试，我是身不由己啊！有什么理由能说服老大不做这些测试啊！！！！！主要是测试收发数据的正确性和速率！！

ding  :mad:

问题解决了
散份了
怎么给分的连接不见了啊？

[编辑 -  5/11/04 by  flyhobo]