Below/attached is a patch that may help to resolve the issues you are
experiencing. It will cause VLAN 0 to be added automatically to the
VLAN filter. Something similar is already done on newer kernels via
changes that were made to support 802.1p and DCB.
--- a/igb_main.c 27 Jun 2011 21:50:11 -0000
+++ b/igb_main.c 27 Jun 2011 22:14:21 -0000
@@ -8120,6 +8120,8 @@ static void igb_restore_vlan(struct igb_
{
igb_vlan_rx_register(adapter->netdev, adapter->vlgrp);
+ igb_vlan_rx_add_vid(adapter->netdev, 0);
+
if (adapter->vlgrp) {
u16 vid;
for (vid = 0; vid< VLAN_N_VID; vid++) {
Thanks,
Alex
On 06/27/2011 03:01 PM, Greg Hupf wrote:
I have some clarification regarding the use of VLAN in PROFINET. The
PROFINET protocol does not specifically use a VLAN ID, but does
specify the packet as VLAN type (0x8100) in order to use the upper
three bits of the VLAN field to specify priority. So even when
PROFINET identifies a packet as VLAN type, it always sets the ID
portion to zero (i.e. the lower 12 bits). From the PROFINET point of
view there is no VLAN, so any VLAN ID=0 should be ignored (i.e. not
dropped as invalid or processed as a valid ID).
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/27/2011 5:29 PM, Greg Hupf wrote:
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 [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/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 [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/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 [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/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:[email protected]]
Sent: Monday, June 27, 2011 9:22 AM
To: Ronciak, John
Cc: [email protected]
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 [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
--- a/igb_main.c 27 Jun 2011 21:50:11 -0000
+++ b/igb_main.c 27 Jun 2011 22:14:21 -0000
@@ -8120,6 +8120,8 @@ static void igb_restore_vlan(struct igb_
{
igb_vlan_rx_register(adapter->netdev, adapter->vlgrp);
+ igb_vlan_rx_add_vid(adapter->netdev, 0);
+
if (adapter->vlgrp) {
u16 vid;
for (vid = 0; vid < VLAN_N_VID; vid++) {
------------------------------------------------------------------------------
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
