Hello John, I ran 'ethtool -S' and 'netstat -s' in an attempt to determine where the packets are being dropped. When the packets are being dropped the ethtool packet counts are less than 10 per second and the netstat packet counts are less than 1 per second. When I enable promiscuous mode the ethtool packet counts increased significantly to almost 100 per second. Initially, when the mode changed, I did see an increase of a dozen or so packets via netstat (probably from the two PNIO devices that were finally able to connect), but there was no change in the steady-state/periodic 'netstat' statistics. Note that the PNIO protocol primarily consists of non-IP packets. This is a private physical network so almost all the traffic is PROFINET related (i.e. other than a few RSTP, MCAST, etc. packets broadcast from the managed switches). Let me know if this is the information you need, or if there is anything else I can do to help further troubleshoot this issue.
Thanks, Greg -- Greg Hupf [email protected] Command and Control Technologies www.cctcorp.com 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 Titusville, Florida 32780 (321) 383-5096 fax On 6/24/2011 7:05 PM, Greg Hupf wrote: > Hello John, > > Thanks for the reply. The device ID is 'E1G44ETBLK' (i.e. Intel Gigabit > ET Quad Port Server Adapter E1G44ET with the 82576 controller). We are > also having the same problem with the Intel adapters located on the > motherboard (with the 82575EB controller). > > All the packets are received correctly in promiscuous mode. But without > promiscuous mode some of the PROFINET packets are dropped (e.g. packets > from managed PROFINET switches are received correctly, but packets from > PROFINET bus couplers are dropped). > > We only seem to have this problem with Intel NICs that use the '82575/6' > controller and/or the 'igb' driver. We tried to do some investigation > using wireshark. I can provide capture files if you think it would be > helpful. Otherwise, I'll see if I can determine if it is the HW or the > stack that is dropping/filtering the packets. Thanks for the help, I > appreciate your cooperation. > > Thanks, > Greg > -- > > Greg Hupf [email protected] > Command and Control Technologies www.cctcorp.com > 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 > Titusville, Florida 32780 (321) 383-5096 fax > > > > On 6/24/2011 4:48 PM, Ronciak, John wrote: >> Sorry to hear of you issue. We need the exact device ID for the NIC's >> to start with. So you are saying that even in promiscuous mode the >> packets are not received correct? Where are the packets being dropped? >> By the HW or by the stack? You can use ethtool and netstat to see >> where they are being dropped. >> >> Let us know about the ID and if you can find where the packets are >> being dropped. >> >> Thanks. >> >> Cheers, >> John >> >> >>> -----Original Message----- >>> From: Greg Hupf [mailto:[email protected]] >>> Sent: Friday, June 24, 2011 11:30 AM >>> To: [email protected] >>> Subject: [E1000-devel] Intel(R) Gigabit ET Quad Port Server Adapter >>> does not work with PROFINET >>> >>> >>> >>> Customer_type: Developer/Designer >>> Product: Intel(R) Gigabit ET Quad Port Server Adapter >>> OS: Red Hat Enterprise Linux 5.0* >>> Kernel: linux-2.6.18-128.el5PAE >>> Distribution_Version: Red Hat Enterprise Linux Server release 5.3 >>> (Tikanga) >>> Issue_Other_Versions: Yes >>> Driver_Version: igb-3.0.22 >>> Issue: We recently purchased two 'Intel(R) Gigabit ET Quad Port Svr >>> Adptr' cards for a large industrial control system. The NIC works fine >>> for most ethernet traffic, but rejects certain PROFINET packets. These >>> packets can only be received if 'promiscuous' mode is enabled. The >>> packets that are rejected are less than 200 bytes, but do use the >>> standard PROFINET VLAN field. Other PROFINET packets are received fine. >>> The network is private and dedicated to PROFINET traffic. The server >>> does not need a VLAN configuration. We replaced the card with an older >>> single-port PRO/1000 NIC (i.e. uses the e1000e driver) and the problem >>> disappears. Other 3-Com and Broadcom NICs also work correctly. We need >>> to get this driver fixed, or get the cards replaced with PRO/1000 based >>> Quad-port NICs. Let me know if you need more information. >>> >>> Thanks, >>> Greg >>> >>> -- >>> Greg Hupf [email protected] >>> Command and Control Technologies www.cctcorp.com >>> 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 >>> Titusville, Florida 32780 (321) 383-5096 fax >>> >>> >>> >>> ----------------------------------------------------------------------- >>> ------- >>> All the data continuously generated in your IT infrastructure contains >>> a definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense.. >>> http://p.sf.net/sfu/splunk-d2d-c1 >>> _______________________________________________ >>> E1000-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/e1000-devel >>> To learn more about Intel® Ethernet, visit >>> http://communities.intel.com/community/wired ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
