Intel X520-SR2 not seeing packets in tcpdump

I have installed an X520 card with the latest driver ixgbe 3.8.  The operating systems is CentOS 5.7. 
When doing an ifconfig I see receive packets.  I also see packets when I do an ethtool -S p1p2.  However,
when I do tcpdump -i p1p2 I see no packets.  Does anyone know why this may be happening.

Re: Intel X520-SR2 not seeing packets in tcpdump

On Thu, Mar 1, 2012 at 11:55, Charles DeVoe <scarecrow_57 <at> yahoo.com> wrote:
> I have installed an X520 card with the latest driver ixgbe 3.8.  The operating systems is CentOS 5.7. 
When doing an ifconfig I see receive packets.  I also see packets when I do an ethtool -S p1p2.  However,
when I do tcpdump -i p1p2 I see no packets.  Does anyone know why this may be happening.
> -

Charles,

I've got some experience with the X520 cards under various flavors of
Linux. I've always had good luck. Although, they do require a bit more
care and feeding than a Copper e1000. Can you be a bit more specific
about what you're seeing?

The other thing I'll throw out there: Do you have vlan tags set on
these packets? If so, you need to add the "vlan" option to tcpdump.
So, on mine:

tcpdump -s 0 -w outfile.pcap -C 500 -i eth4 vlan

Keep us posted.

MJ

Re: Intel X520-SR2 not seeing packets in tcpdump

On Mar 1, 2012, at 3:39 PM, Mark W. Jeanmougin wrote:

> On Thu, Mar 1, 2012 at 11:55, Charles DeVoe <scarecrow_57 <at> yahoo.com> wrote:
>> I have installed an X520 card with the latest driver ixgbe 3.8.  The operating systems is CentOS 5.7.  When
doing an ifconfig I see receive packets.  I also see packets when I do an ethtool -S p1p2.  However, when I do
tcpdump -i p1p2 I see no packets.  Does anyone know why this may be happening.
>> -
> 
> Charles,
> 
> I've got some experience with the X520 cards under various flavors of
> Linux. I've always had good luck. Although, they do require a bit more
> care and feeding than a Copper e1000. Can you be a bit more specific
> about what you're seeing?
> 
> The other thing I'll throw out there: Do you have vlan tags set on
> these packets? If so, you need to add the "vlan" option to tcpdump.

That should only be necessary if you're capturing with a filter; if the command is just

	tcpdump -i p1p2

then no filter was specified, so "vlan" shouldn't be necessary and will, in fact, *reduce* the number of
packets (as it'll mean capturing only packets with VLAN tags).

"vlan" is used when its side-effect, of causing other filters to go past the VLAN tag and look at the actual
Ethernet type field, is desired, e.g. if you have tagged packets, "host foobar" won't work as it won't
recognize IPv4 or IPv6 packets, you'd need either

Re: pcap DLT request for virtio-scsi SCSI transport

On Tue, Feb 28, 2012 at 11:05 AM, Stefan Hajnoczi <stefanha <at> gmail.com> wrote:

Sorry for the delay, I didn't realize you had replied.  I am not
subscribed to this mailing list, please Reply-All and keep me CCed.

>> The QEMU system emulator now supports the virtio-scsi SCSI transport
>> for efficient virtualized SCSI I/O.  I would like to support
>> virtio-scsi debugging and analysis with pcap.
>>
>> The pcap data will include the virtio buffers containing SCSI command
>> metadata, CDB, and data-out buffer.  A similar structure is also used
>> for SCSI responses with the data-in buffer and a footer.
>>
>> You can find detailed information on virtio-scsi in Appendix H of the
>> virtio specification:
>> http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.4.pdf
>
> OK, so what does a single packet look like?  Does each packet correspond to a single SCSI command or response?

There are SCSI commands and responses.  Commands and responses are
separate pcap packets because there can be multiple outstanding
commands to multiple targets/LUNs.

From the spec, commands have the following layout:

    u8 lun[8];
    u64 id;
    u8 task_attr;
    u8 prio;
    u8 crn;

[PATCH] Avoid losing CPPFLAGS in configure.in

Hi,

Simon Ruderich <simon <at> ruderich.org> found that tcpdump's configure script
loses the value of CPPFLAGS because the save/restore code has a typo.
He provided the following patch to fix the problem:

diff --git a/configure.in b/configure.in
index 4ac664e..2bf219c 100644
--- a/configure.in
+++ b/configure.in
 <at>  <at>  -732,7 +732,7  <at>  <at>  if test $ac_cv_func_pcap_findalldevs = "yes" ; then
 dnl Check for Mac OS X, which may ship pcap.h from 0.6 but libpcap may
 dnl be 0.8; this means that lib has pcap_findalldevs but header doesn't
 dnl have pcap_if_t.
-    savedppflags="$CPPLAGS"
+    savedcppflags="$CPPFLAGS"
     CPPFLAGS="$CPPFLAGS $V_INCLS"
     AC_CHECK_TYPES(pcap_if_t, , , [#include <pcap.h>])
     CPPFLAGS="$savedcppflags"

--

-- 
Romain Francoise <rfrancoise <at> debian.org>
http://people.debian.org/~rfrancoise/

configure stage problem tcpdump 4.2.1

Dear Sirs,

I have some problem with install tcpdump latest version .
I have installed libpcap 1.2.1 form tcpdump site and when I want install 
tcpdump , I can't go trough configure stage .
I include config.log file

Yours faithfully, Maciek P.

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.61.  Invocation command line was

  $ ./configure --prefix=/usr

## --------- ##
## Platform. ##
## --------- ##

hostname = mac-deb
uname -m = x86_64
uname -r = 2.6.32-5-amd64
uname -s = Linux
uname -v = #1 SMP Mon Jan 16 16:22:28 UTC 2012

/usr/bin/uname -p = unknown

Re: configure stage problem tcpdump 4.2.1

On Mar 3, 2012, at 9:11 AM, MacPir wrote:

> I have some problem with install tcpdump latest version .
> I have installed libpcap 1.2.1 form tcpdump site and when I want install tcpdump , I can't go trough
configure stage .
> I include config.log file

As in all these "pcap_parse not found" cases, that's a problem with libpcap, so we'd need the config.log
file, and the output of the build process, for libpcap.

(I'm going to change the configure file to ask for that explicitly in that case.  People keep reporting this
problem - which I haven't been able to reproduce on any of the Linux distributions on which I've tried it -
and I keep asking for the additional information, but nobody bothers to give us the libpcap config.log
file or build process output, so we can't figure out why it's happening, and thus can't fix it.)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.

Re: [PATCH] Avoid losing CPPFLAGS in configure.in

On Mar 3, 2012, at 8:51 AM, Romain Francoise wrote:

> Simon Ruderich <simon <at> ruderich.org> found that tcpdump's configure script
> loses the value of CPPFLAGS because the save/restore code has a typo.
> He provided the following patch to fix the problem:

Selecting and copying the patch and doing

	pbpaste | patch -p1

didn't work - but that's actually a good thing, as it meant I decided to go in and edit configure.in myself,
which I did with a global search and replace, and found that there were *two* places where it referred to
"CPPLAGS" rather than "CPPFLAGS", so I fixed them both.

Checked into the trunk and 4.2 branches.

Re: [PATCH] Avoid losing CPPFLAGS in configure.in

Guy Harris <guy <at> alum.mit.edu> writes:

> Checked into the trunk and 4.2 branches.

Thanks, but I should have made it more explicit that the patch fixes *two*
typos: 'savedppflags' vs. 'savedcppflags' and 'CPPLAGS' vs. 'CPPFLAGS'.
You fixed only the latter, so the following is still necessary after your
commit:

diff --git a/configure.in b/configure.in
index f1300d7..8864238 100644
--- a/configure.in
+++ b/configure.in
 <at>  <at>  -732,7 +732,7  <at>  <at>  if test $ac_cv_func_pcap_findalldevs = "yes" ; then
 dnl Check for Mac OS X, which may ship pcap.h from 0.6 but libpcap may
 dnl be 0.8; this means that lib has pcap_findalldevs but header doesn't
 dnl have pcap_if_t.
-    savedppflags="$CPPFLAGS"
+    savedcppflags="$CPPFLAGS"
     CPPFLAGS="$CPPFLAGS $V_INCLS"
     AC_CHECK_TYPES(pcap_if_t, , , [#include <pcap.h>])
     CPPFLAGS="$savedcppflags"
 <at>  <at>  -1067,7 +1067,7  <at>  <at>  if test "$want_libcrypto" != "no"; then
 		fi
 		AC_CHECK_LIB(crypto, DES_cbc_encrypt)

-		savedppflags="$CPPFLAGS"
+		savedcppflags="$CPPFLAGS"
 		CPPFLAGS="$CPPFLAGS $V_INCLS"
 		AC_CHECK_HEADERS(openssl/evp.h)

Re: [PATCH] Avoid losing CPPFLAGS in configure.in

On Mar 4, 2012, at 4:23 AM, Romain Francoise wrote:

> Guy Harris <guy <at> alum.mit.edu> writes:
> 
>> Checked into the trunk and 4.2 branches.
> 
> Thanks, but I should have made it more explicit that the patch fixes *two*
> typos: 'savedppflags' vs. 'savedcppflags' and 'CPPLAGS' vs. 'CPPFLAGS'.
> You fixed only the latter, so the following is still necessary after your
> commit:

Checked into the trunk and 4.2 branches.