Solved: packet-capture filters

WILLIAM STEGMAN · ‎12-30-2013

Has anyone successfully used a source-port or destination-port filter in a packet-capture command on a waas? Anytime I try to filter on any port # I capture no packets. If I however remove the port # and run a packet-capture I capture packets and see the traffic my filter should have caught. I'm not sure if I'm looking at a bug since it seems straightforward.

packet-capture interface gigabitEthernet 0/0 source-port 1494 file-size 50000 capctx

Cisco Wide Area Application Services (universal-k9) Software Release 5.1.1d (build b7 Aug 19 2013)

Version: oe7571-5.1.1d.7

thank you,

Bill

finn.poulsen · ‎01-02-2014

Both,

Is the traffic GRE encapsulated ?

Please be aware of this BUG :

CSCue93327

Even though it specifies an APP-Nav environment, I think the GRE issue is still there.

And the issue can still be problematic with tethereal and the "-f" option.

It seams that the bug is solved in 5.3(0.26) ... whatever that is.

Best regards

Finn

View solution in original post

Srinivasan Aylur Narayanan · ‎12-30-2013

Hi william,

Please try to capture using tcpdump command

for example

tcpdump -s 0 tcp port 1494 -i eth0 -w filename.pcap <<<<<<<<<<

This will capture any communication from or to the tcp.port == 1494

and make sure the eth0 is the primary interface in the configuration

The most useful tcpdump options are as follows:

-i

interface

: The interface where you want to capture packets, for example:

lo : localhost
eth0 : GigabitEthernet 1/0
eth1 : GigabitEthernet 2/0
-s snaplen: The maximum size that will be captured for each packet.(to capture size upto 65535 bytes)
-w file: The name of the file where the captured packets will be written in their raw form.

for more examples refer to the following ink

http://www.tcpdump.org/tcpdump_man.html

WILLIAM STEGMAN · ‎12-31-2013

Thank you Srinivasa. I tried the tcpdump, but get the same behavior. As soon as I remove the filter all the packets come pouring in. I've tried different ports such as 445, but with the same results, 0 packets.

pa-harr-0-7571a#tcpdump -i eth0 -s 3200 tcp port 1494 -w ctxcapnew.pcap

Note : The tcpdump and tethereal CLIs are planned to be deprecated in a future release. The use of 'packet-capture' CLI is recommended.

tcpdump: Setting virtual memory/file size limit to 524288000

tcpdump: WARNING: eth0: no IPv4 address assigned

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 3200 bytes

0 packets captured

12 packets received by filter

0 packets dropped by kernel

pa-harr-0-7571a#tcpdump -i eth0 -s 3200 -w ctxcapnew1.pcap

Note : The tcpdump and tethereal CLIs are planned to be deprecated in a future release. The use of 'packet-capture' CLI is recommended.

tcpdump: Setting virtual memory/file size limit to 524288000

tcpdump: WARNING: eth0: no IPv4 address assigned

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 3200 bytes

225215 packets captured

225222 packets received by filter

0 packets dropped by kernel

Update on this:

tethereal seems to be the only utility that works with a filter. The command below performed as expected, which is odd since it's advertised as working with 4.0 and earlier and I'm running 5.1.1d where I'm warned that tethereal and tcpdump are soon to be deprecated; hopefully not before the issue with packet-capture not working with filters is resolved.

tethereal -i eth0 -s 1600 -w dump.cap -R "tcp.port == 1494"

Srinivasan Aylur Narayanan · ‎12-31-2013

Hi William,

This looks like a bug to me..you could open a TAC case to verify this behaviour.

Thanks

Srinivasan

finn.poulsen · ‎01-02-2014