On 9/1/07, Guy Harris <[EMAIL PROTECTED]> wrote:
> If you make any other changes, as per the suggestions below, also change
> FILES in the new patch.
Ack
It also duplicates what's in pcap.3; the problem is that changes to
> pcap.3 might render the duplicated stuff out of date.
>
> A document that assumes the reader has already read the libpcap man
> page, and just explains what's different about the ACN version, might
> require less maintenance.
OK. I'll change it.
>> It sounds as if IOP-type devices have names with
> >> a particular format that isn't likely to match the name of a regular
> >> Linux networking device, so it should, I think, be possible to support
> >> both.
> >
> > You are correct, I intentionally tried to ensure that my naming
> > convention was different than that of the other OS I was aware of...
>
> Then, in that case, one version of libpcap could handle both.
>
> > So the usual time/budget constraints made me separate the two
> > functionalities as much as possible. And... I didn't want to 'polute'
> the
> > pcap-linux.c file any more than I had to, so I would not confuse
> people
> > that followed me in non-ACN-land with un-related code.
>
> pcap-linux.c already has extra stuff to check for a variety of optional
> device types; pcap_open_live() would just have
>
> if (the device looks like an ACN device) {
> return acn_open_live(device, snaplen, promisc, to_ms,
> ebuf);
> }
>
> added to it, along with all the other checks.
I might have done that except that I didn't understand what the rest
of the code in open_live() did, so I didn't want to disable it and/or
replicate it, I just added my code within an ifdef).
As it is, the code sample above does have #ifdefs around it,
and I've done effectively the same thing.
On the other hand, I've left it open so that _my_ equipment can
change/add device names without having to alter pcap code rather
than embedding SITA rules within 'nix pcap code.
At some point I'll probably look at making it easier to add hooks for
> other device types without modifying pcap_open_live().
>
> That would allow users to build libpcap with ACN support, and (with the
> top-of-tree version, to which the ACN support would be added) install it
> as a shared library, which would mean that applications that can handle
> DLT_SITA would handle your devices *without having to be recompiled*.
But my device, isn't a device, its a mode of operation/network protocol.
Its effectively a 'remote/distributed' sniffer. I understand there
is something like that for Windows, where you can use wireshark to
attach to a remote wpcap to receive data.
Thats what mine does, except it also knows how to go out to find
the remotely sniffable machines (and their interfaces).
(Unfortunately) I had already finished my approach by the time I found
this remote MSWindows version. And besides: a) I probably had more
requirements than that code provided and b) I'd needed to start
with libpcap because the machine that runs tshark/wireshark _is_
a Linux box.
If you don't have time to add a check like that, just indicate what
> names it should check for, and I can add that support.
I thought about this all weekend, and its more complicated than that.
My system, although when it comes to the monitoring part does
have somewhat unique startup. In my patch (v2) I discovered
and have now split out my own verssion of fad_xxx.c
Its because of this code, that I really have my own libpcap library
(compile for SITA versus compile for xxx). Although it could,
I don't think this code should always be included because of the
special things (ie. lots of TCP sessions at startup) it does to
find remote interfaces on networked devices to monitor.
Burdening normal 'nix users with this overhead is not reasonable.
I'd need to have a command line switch or config option in tcpdump,
Wireshark, tshark to enable/disable this mode (and I don't want
to add that much complexity right now just to make the operation
(semi-) transparent. I think the code is better when its more
obvious, segregated and less intrusive.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
