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 > <[email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> Aaron Turner wrote: >>>>>> On Wed, May 6, 2009 at 8:59 PM, Michael Tüxen >>>>>> <[email protected]> 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 <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
