Hi Aaron,
being able to capture from multiple packets is a feature
requested by multiple people. Therefore, and because
I also need it, I'm (trying to) implement it.
Generating different .pcap files and combing them
with mergecap during postprocessing is how I do this
currently , but I would like to improve this.
Please note that when using Wireshark you use a GUI
which generate the command line to invoke dumpcap.
But tshark, wireshark and dumpcap share a lot of
the code processing the command line arguments,
so the possibilities might eventually also
show up in tshark and wireshark...
Best regards
Michael
On May 7, 2009, at 3:47 PM, Aaron Turner wrote:
On Thu, May 7, 2009 at 12:26 PM, Michael Tüxen
<Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
On May 7, 2009, at 2:34 PM, Nathan Jennings wrote:
On 5/7/2009 9:10 AM, Sébastien Tandel wrote:
On Thu, May 7, 2009 at 03:05, Stephen Donnelly <stephen@xxxxxxxxxx>
wrote:
Aaron Turner wrote:
On Wed, May 6, 2009 at 8:59 PM, Michael Tüxen
<Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote:
On May 6, 2009, at 3:40 PM, Aaron Turner wrote:
I think this is confusing to many people and is more likely to
have
unintended consequences. Most users don't consider CLI option
ordering to have special meaning. Personally, I prefer Stephen's
suggestion of directly linking the filter to the interface ala -i
en0:"sctp && host a.b.c.d" if you want to get fancy.
It also means the old style cli args could easliy be grand-
fathered in
(any interface without a specific filter uses the global filter).
Completely agree to define something which is explicitly linked to
which
interface the filter belongs. Ordering parameters is not intuitive.
I you do decide to go this way, ':' might not be the best delimiter
character to use. It is already used in libpcap interface names
and
could cause parsing headaches.
I think some OSes use ':' in vlan interface names? Also ':' is
used in
dag interface names to indicate sub streams, e.g. "dag0:2".
':' is indeed confusing. It is used by Linux to define virtual
interfaces
like eth0:1
I had also thought of suggesting ":", but see the overloading
problem
now as Stephen D. pointed out... which reminded me of maybe another
potential clash:
From a "preferences" file:
<... snip ...>
# Interface descriptions.
# Ex: eth0(eth0 descr),eth1(eth1 descr),...
capture.devices_descr: \Device\NPF_{"Windows-string"}(Intel NIC)
</snip>
... although I can't think of a clash with this off-hand right now.
Maybe this is better?:
dumpcap -n -i dag0:2,"sctp && host 1.2.3.4" -i en0
In the parser, you should probably check for and allow use of single
quotes too (e.g. shell scripts), like:
dumpcap -n -i dag0:2,'sctp && host 1.2.3.4' -i en0
But we also have -y and -s... So taking this path requires something
like
-i interface_name,capture_filer,link_type,snap_length
How does this look like?
ugh. I think you've reached the point IMHO where you should just use
two different instances of tcpdump to capture the packets. It
wouldn't be difficult to write a tool which would interleave the
packets from multiple pcap files into a single using the timestamp for
ordering... that way you can capture on as many interfaces with
different options, even from different systems as you want without
resorting to CSV hell.
My .02.
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for
Unix & Windows
Those who would give up essential Liberty, to purchase a little
temporary
Safety, deserve neither Liberty nor Safety.
-- Benjamin Franklin
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe