Ethernet Products
Determine ramifications of Intel® Ethernet products and technologies
4529 Discussions

I350-T4 Wireshark/WinPcap single port: Revised


PC: WinXP-Pro SP3 : Problem appears to be with XP SP3

NIC: I350-T4

Am using WinPcap SendQue with SendQueueTransmitModes.Synchronized to send Ping from I350-T4 port 1 ( to I350-T4 port 2 ( on same PC. Ports are connected thru switch. I have Wireshark monitoring both IP addresses.

If I did this with XP SP2 and 2 discrete NICs (Intel Gig CT ) I see ICMP request and ICMP replies on both wireshark sessions.

If I do this now XP SP3, I see only address 201 requests on both wire shark sessions and no address 202 replies. Inspection of switch shows that correct number of ICMP packets Tx/Rx both ports. NIC is not configured for teaming.

Application is to test switch thru put from single PC. Any ideas as to why I350-T4 different from discrete NICs

0 Kudos
1 Reply

I do not have an answer (or at least not yet), but your results have provided for an interesting discussion. The IntelR) Ethernet I350 server adapters use the latest gigabit Ethernet controller from Intel with more features available than in the older, discrete adapters you used. Another big difference is that the way the adapters connect to the PCI-Express bus will be different. Whether either of those differences will have anything to do with the differences in your results remains to be seen.

Some options in the way the new adapters might implement some features can exist between different versions of the adapter, like an OEM version versus a retail adapter. So knowing the PBA number will help us identify which adapter you have. If you used the default software installation, you have a tab in Windows Device Manager for Link Speed, which includes an identify adapter button. That button will bring up the PBA number and a few other details about the adapter. Please let us know what PBA number you have.

Another thing I have been thinking about is whether the packets are missing from the WIreshark capture because some controller feature is offloading or doing some type of direct memory transfer that causes the packet not to show up in the capture. I don't have any particular reason to think that is the cause, but I thought we could try putting the adapter into a promiscuous mode where everything is being passed up the stack. Try setting MonitorMode to a value of 2 as described at Using a value of 2 will probably break any VLANs if you are using them. You can set the value to zero when you are finished with the experiment to make sure nothing else gets broken. Let us know if changing this setting makes the missing packets appear in the capture. Be sure to disable and then enable the adapter to pick up the registry changes. These changes will not take affect until the adapter is restarted (or Windows is restarted or forced to read the registry changes.)

If you have any other thoughts about this, feel free to share them. If we keep digging we should be able to figure out what is going on.

Mark H

0 Kudos