12-30-2013 12:40 PM
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
Solved! Go to Solution.
01-02-2014 06:54 AM
Both,
Is the traffic GRE encapsulated ?
Please be aware of this BUG :
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
12-30-2013 09:33 PM
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:
for more examples refer to the following ink
12-31-2013 06:54 AM
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"
12-31-2013 10:06 PM
Hi William,
This looks like a bug to me..you could open a TAC case to verify this behaviour.
Thanks
Srinivasan
01-02-2014 06:54 AM
Both,
Is the traffic GRE encapsulated ?
Please be aware of this BUG :
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
01-02-2014 07:05 AM
It is using GRE. Thanks Finn. I'll look for the functionality after our next upgrade.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide