This brings up another possibility: separate capturing from dissection
in a more "radical" way. If we're doing so, we then also need to
investigate whether we're still able to do the "stop condition" checks
etc, but I don't think this is impossible to do.
The packet capture subsystem could return a file handle or file
descriptor to Ethereal, so there is little or no impact on the system.
We could also say that the packet capture engine should run at higher
priority than the packet dissection engine, hence using the capture
file as a buffer.
If we need to caprure on multiple devices, we can hide this from
Ethereal by inserting this magic into the capture engine.
Additionally, we could add support for remote capturing and for
network taps via an API similar to the libpcap or wiretap API. As a
result, Ethereal would indeed only know about display filters (which I
*really* want to be renamed to *dissection filters* as I think that's
a more intuitive name for those), and the interaction with packet
capturing would be hidden by the file descriptor.
I'd really love comments from experienced prgrammers on this!
Maybe we could create an ad-hoc mailing list "ethereal-arch"
discussing architecture stuff and maybe redefining the goals for a
version 1.0.
Regards,
Olivier
-- Original message:
From: "Ulf Lamping"
| Hi List!
|
| Currently, Ethereal can only capture from one interface at once.
|
| To be able to capture on a full duplex Ethernet without interfering
the
| net, you have to think about how to do this.
| As some of my colleques are doing network troubleshooting, they have
a
| problem here.
|
| The usual network troubleshooter will connect a notebook to the
existing
| ethernet "somehow".
| It's preferrable to change the existing network at minmal as
possible,
| as it will modify the network itself,
| and the network professionals at that place will not be pleased, if
you
| install several new hardware components to
| their network, so:
|
| a) if you use a hub, this will switch back the connection to
halfduplex
| b) if you add a managable switch (with a monitoring port), this will
| change the network configuration
| and these devices are sometimes not easy to configure themself (so
you
| add another point of failure)
| c) add a network tap
|
| To c): a network tap is plugged between a switch and the device
under
| test and
| will be (almost) passive to the measured network. It will hand out
both
| directions of the full duplex connection with two
| ethernet plugs. So if you want to capture now, you must do this from
two
| ethernet interface at once.
|
| BTW: we might need a HowTo, which describes the possible ways for
| connection Ethereal to an existing network,
| as this isn't obvious for some (network novice) user.
|
| Now Ethereal comes in the discussion:
|
| a) you cannot capture from multiple interfaces at once :-(((
| b) you can capture using multiple instances of Ethereal and merge
them
| together using mergecap, but thats very uncomfortable :-(
| c) as far as I know, on unix (linux only?) you can use an "all"
| interface, which will capture from all interface at once.
| But as I'm (and "my users") are usually using the Win32 platform,
this
| doesn't help me very much :-(
| d) use a completely different tool for capturing and doing only the
| analyzing in Ethereal, but thats not very comfortable, too :-(
|
| As it's been one strong criteria against Ethereal and for some other
| analyzer, I'm thinking about how this could be changed.
| I currently see the following solutions (most interesting first):
|
| a) enable Ethereal to capture from multiple interfaces at once and
do
| the merging "on the fly"
| b) enable Winpcap to support the "all" interface, like in the unix
versions
| c) integrate a seperate capture tool into the GUI, which is capable
of
| doing multiple interface capturing
|
|
| I understand this might be a lot of work, but as this is a
limitation
| and becoming more and more a criterion for not using Ethereal at
all,
| I think this effort should be spend.
|
| Before doing anything on the code, I would like to hear some
comments
| about this.
|
| Regards, ULFL
|
| _______________________________________________
| Ethereal-dev mailing list
| Ethereal-dev@xxxxxxxxxxxx
| http://www.ethereal.com/mailman/listinfo/ethereal-dev