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
