Persistently Capturing VLAN Tags with Intel Pro/1000 CT NIC Card under CentOS 6.3

Question

I am in need to capture packets that contain VLAN tags on my Intel Pro/1000 CT NIC Card.

When I try to capture packets using the command: tcpdump -ni eth2 vlan

I do NOT capture any packets.

I then issue the command: ifconfig eth2 mtu 1522

I then try to capture packets using the command: tcpdump -ni eth2 vlan

I CAN now capture packets

I then save my settings in my cfg file: /etc/sysconfig/network-scripts/ifcfg-eth2

Please read /usr/share/doc/initscripts-*/sysconfig.txt
for the documentation of these parameters.
DEVICE=eth2
BOOTPROTO=none
NETMASK=255.255.255.0
TYPE=Ethernet
IPADDR=10.2.1.1
HWADDR=00:1b:21:a0:17:27
MTU=1522

I then reboot the computer.

After the reboot I issue the command: tcpdump -ni eth2 vlan

Now NO packets are captured.

I check the interface settings using: ifconfig eth2

The MTU setting is still there:

ifconfig eth2

eth2 Link encap:Ethernet HWaddr 00:1B:21:A0:17:27
inet addr:10.2.1.1 Bcast:10.2.1.255 Mask:255.255.255.0
inet6 addr: fe80::21b:21ff:fea0:1727/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1522 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:120 (120.0 b) TX bytes:4181 (4.0 KiB)
Interrupt:17 Memory:f0680000-f06a0000

I then issue the command: ifconfig eth2 mtu 1524 and ifconfig eth2 mtu 1522
(Toggling the MTU setting)

I then try to capture packets using the command: tcpdump -ni eth2 vlan

I CAN now capture packets

Any idea how to make the ability to capture packets permanent between reboots?

Thanks in advance for any wisdom and guidance!!

-John

Various settings:

ifconfig eth2

eth2 Link encap:Ethernet HWaddr 00:1B:21:A0:17:27
inet addr:10.2.1.1 Bcast:10.2.1.255 Mask:255.255.255.0
inet6 addr: fe80::21b:21ff:fea0:1727/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1522 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:120 (120.0 b) TX bytes:4181 (4.0 KiB)
Interrupt:17 Memory:f0680000-f06a0000

ethtool -i eth2

driver: e1000e
version: 1.9.5-k
firmware-version: 1.8-0
bus-info: 0000:30:00.0

modinfo -d -p e1000e

EEE:Enable/disable on parts that support the feature
CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC
WriteProtectNVM:Write-protect NVM [WARNING: disabling this can lead to corrupted NVM]
KumeranLockLoss:Enable Kumeran lock loss workaround
SmartPowerDownEnable:Enable PHY smart power down
IntMode:Interrupt Mode
InterruptThrottleRate:Interrupt Throttling Rate
RxAbsIntDelay:Receive Absolute Interrupt Delay
RxIntDelay:Receive Interrupt Delay
TxAbsIntDelay:Transmit Absolute Interrupt Delay
TxIntDelay:Transmit Interrupt Delay
copybreak:Maximum size of packet that is copied to a new buffer on receive

lspci

20:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
30:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

ethtool eth2

Settings for eth2:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000001 (1)
Link detected: yes

Answer 1

0

sounds like a problem with the driver or the hardware itself. Did you try to capture on the other 82574L adapter?

BTW: You could try to boot the PC from Knoppix and/or BackTrack Live CD and check if you can capture. If it work, it might be a driver problem in CentOS 6.3. If it does not work it might be a problem with the adapter itself.

Regards
Kurt

answered 01 Nov '12, 14:54

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Hi Kurt,

It will be very difficult to try and use a live CD as the problem is that this is a headless setup.

Both Intel interfaces behave the same.

If I use a Broadcom based NIC I have no problem capturing.

So this issue is somewhat related to the hardware and options with the driver for the Intel NIC.

In the past Broadcom support gave me a procedure for updating parameters in the firmware to allow VLAN tagged packets to be captured.

INTEL is refusing to assist in resolution so I am trying to procure Broadcom based NICs.

The fact that I can get it to work but it is not persistent over a restart is puzzling and points to a combo driver/hardware issue.

Words of wisdom are welcome. :-)

-John

(02 Nov '12, 05:44) xq1

I've converted your "answer" to a comment as that's how this site works, please see the FAQ.

There are occasions when you have to post a comment as an answer, e.g. if your comment is long, but otherwise replies to answers or other comments should be made as comments.

(02 Nov '12, 05:52) grahamb ♦

Answer 2

I did this by adding the following lines to /etc/rc.local because I was running into the same issue configuring it in the network script file on Centos 6.3

/sbin/ifconfig eth1 0.0.0.0 promisc up mtu 1524
/bin/sleep 2
/sbin/ifconfig eth1 0.0.0.0 promisc up mtu 1522

The problem with not being able to see tagged traffic was driving me crazy and I was on a wild goose chase looking at my libpcap version until I ran across this article.