Menu
▾
▴
Re: [E1000-devel] Intel(R) Gigabit ET Quad Port Server Adapter does not work with PROFINET
|
From: Greg H. <hu...@cc...> - 2011-06-27 21:29:13
|
Hello Alex, I am not 100% sure about the relationship between PROFINET and VLAN. I know that PROFINET augments the VLAN field with a special Ethertype 0x8892, but descriptions of the specification seem to indicate that the VLAN field is optional. Looking at empirical data from the wireshark captures, I can see that some PROFINET devices add 0x8100 at the end of the Ethernet II header where wireshark identifies this field as VLAN type. The vconfig command does not seem to support VLAN IDs greater than 4096, so it is not clear that the 0x8100 is actually intended as a VLAN ID. The wireshark capture I posted contains this information (e.g. see frame #5). Thanks, Greg -- Greg Hupf hu...@cc... 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/27/2011 4:00 PM, Alexander Duyck wrote: > Greg, > > You mentioned that the PROFINET interface was using a VLAN. Do you > recall what the VLAN ID was that was in use? > > You will likely need to add said VLAN to the configuration for the > interface vi either the ip command or vconfig. This is because by > default VLAN filtering is enabled on the igb driver and this is likely > what is causing your packets from the PROFINET interface to be > dropped. I'm fairly certain this is the case as we normally use > promiscuous mode as a means of also disabling VLAN filtering. > > Also I suspect the other adapters you tested may only be working due > to a flaw in the code. On older kernels most network drivers would > pass VLAN tagged frames as untagged traffic when there were no VLANs > configured on the interface. If you were to configure a VLAN that did > not match the PROFINET VLAN on any of those interfaces I suspect they > would be dropping your packets as well. > > Thanks, > > Alex > > On 06/27/2011 10:34 AM, Greg Hupf wrote: >> Hello John, >> >> Attached is a tarball 'igbPnioInfo.tgz' (13824 bytes) that contains >> five text files: >> >> lspci.txt: Updated lspci info (lspci -vv, -n, and -nn), the previous >> lspci data was limited because I forgot to run as root. >> >> ethtool.noPromisc: Output from 'ethtool -d' with promiscuous mode >> disabled. The output from ethtool was captured once a second for >> approx 15 seconds while the PNIO devices were trying to connect. >> >> ethtool.withPromisc: Output from 'ethtool -d' as promiscuous mode was >> enabled and the PNIO devices were able to connect. The output from >> ethtool was captured once a second for approx 20 seconds. Initially, >> promiscuous mode is not enabled (first 3-5 seconds), then enabled and >> wait until all connections completed successfully. >> >> netstat.noPromisc: Output from 'netstat -s --raw' with promiscuous >> mode disabled. The output from netstat was captured once a second for >> approx 20 seconds while the PNIO devices were trying to connect. >> >> netstat.withPromisc: Output from 'netstat -s --raw' as promiscuous >> mode was enabled and the PNIO devices were able to connect. The >> output was captured once a second for approx 20 seconds. Initially, >> promiscuous mode is not enabled (first 3-5 seconds), then enabled and >> wait until all connections completed successfully. >> >> >> >> >> Greg Hupf hu...@cc... >> 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/27/2011 12:36 PM, Greg Hupf wrote: >>> Hello John, >>> >>> Thanks for the reply. The attached file 'lspci.txt' contains the >>> outputs >>> from 'lspci -vv' and 'lspci -nn'. The '-vv' output is first, >>> followed by >>> the vendor and device codes. I'll send the ethtool and netstat next. >>> >>> Thanks, >>> Greg >>> >>> -- >>> >>> Greg Hupf hu...@cc... >>> 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/27/2011 12:26 PM, Ronciak, John wrote: >>>> OK, please get us the 'lspci -nn' data. The output from the both the >>>> ethtool and netstat commands would also help. We just want to see how >>>> the HW and stack see these non-ip packets. >>>> >>>> Thanks. >>>> >>>> Cheers, >>>> John >>>> >>>> >>>>> -----Original Message----- >>>>> From: Greg Hupf [mailto:hu...@cc...] >>>>> Sent: Monday, June 27, 2011 9:22 AM >>>>> To: Ronciak, John >>>>> Cc: e10...@li... >>>>> Subject: Re: [E1000-devel] Intel(R) Gigabit ET Quad Port Server >>>>> Adapter >>>>> does not work with PROFINET >>>>> >>>>> >>>>> 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 hu...@cc... >>>>> 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 hu...@cc... >>>>>> 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:hu...@cc...] >>>>>>>> Sent: Friday, June 24, 2011 11:30 AM >>>>>>>> To: e10...@li... >>>>>>>> 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 hu...@cc... >>>>>>>> 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 >>>>>>>> E10...@li... >>>>>>>> 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 >> E10...@li... >> https://lists.sourceforge.net/lists/listinfo/e1000-devel >> To learn more about Intel® Ethernet, visit >> http://communities.intel.com/community/wired > |