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 | [EMAIL PROTECTED] | http://www.ethereal.com/mailman/listinfo/ethereal-dev _______________________________________________ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev
