On Aug 31, 2017, at 3:37 AM, Ed Beroset <[email protected]> wrote:
> On 08/30/2017 09:31 PM, Guy Harris wrote: >> On Aug 30, 2017, at 6:00 PM, Ed Beroset <[email protected]> wrote: >>> One problem is that as dumpcap is currently written, it treats files and >>> pipes very differently. >> *Files* and pipes, or *capture devices* and pipes? > > Actually, I meant to say pipes and sockets. That's because 1) UN*Xes tend to support select()/poll()/epoll()/kqueues/etc. on just about all descriptors while 2) Windows doesn't support the WaitFor APIs on all handles, and pipes are different from sockets. >>> but I can't help but think that the general approach you describe is the >>> better long term strategy. >> Probably. It means that the interface between *shark and extcap programs >> would be different - but, while having extcap programs behave like dumpcap >> might complicate the extcap programs (although some of the code to do that >> could be in a library used by dumpcap and by extcap programs), it might >> simplify the Wireshark capture code path. > > I'm not sure that the interface between dumpcap and Wireshark/tshark would > need to change to accommodate a wider variety of inputs via pipes. It wouldn't. The interface between *extcap programs* and Wireshark/tshark would need to change if we want to have extcap programs work like dumpcap, so that they talk directly to Wireshark/tshark, and write directly to a capture file, rather than talking to dumpcap by sending packets over a pipe. That was Stephen's suggestion, and I think it's worth considering. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
