Re: [tcpdump-workers] Where to put the TcApi.h?
OK. I have removed the macro and the source files related to TurboCap API in https://github.com/the-tcpdump-group/libpcap/pull/511. Cheers, Yang On Thu, Jun 30, 2016 at 6:27 PM, Guy Harris wrote: > On Jun 30, 2016, at 3:14 PM, Yang Luo wrote: > > > TcApi.h is contained in WinPcap but not in libpcap. Where to put it? > > Put it in the devpack/include directory underneath the directory in which > the TurboCap API: > > > https://support.riverbed.com/content/support/software/steelcentral-npm/turbocap.html > > is installed. > > I.e., it's not, and should not be, part of libpcap/WinPcap/Npcap. It > should be part of the TurboCap API; if you don't have the TurboCap API, you > shouldn't define HAVE_TC_API and shouldn't build pcap-tc.c - pcap-tc.c is > for use with TurboCap cards, and requires the TurboCap API. > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Remove the eproto_db symbol exporting to keep the DLL delay-load feature on Windows
OK. I will try my best to keep this structure exported, if it can't be done, I will only remove the export on Windows. Cheers, Yang On Thu, Jun 30, 2016 at 1:14 PM, Guy Harris wrote: > On Jun 27, 2016, at 10:56 PM, Yang Luo wrote: > > > Because of libpcap has exported the a data structure called eproto_db ( > https://github.com/the-tcpdump-group/libpcap/blob/master/nametoaddr.c#L320), > when I compiled WinDump in MSVC specifying "wpcap.dll" as a delay loaded > DLL, I encountered the link error 1194. The cause is here: > https://msdn.microsoft.com/en-us/library/w59k653y%28v=vs.80%29.aspx?f=255&MSPPError=-2147217396 > . > > > > Delay loading wpcap.dll is an important part for the switch between > Npcap mode and WinPcap mode. And from the comment, it seems that exporting > this data is not very critical. So can we remove the "PCAP_API_DEF" at the > line beginning to disable the exporting? > > What the comment says is > > * tcpdump used to import this, and it's declared as an export on > * Debian, at least, so make it a public symbol, even though we > * don't officially export it by declaring it in a header file. > > which means that if we stop exporting it on UN*X, Debian might have to > deem that an incompatible change to the ABI and that might cause > significant disruption on Debian and its derivatives. > > Other UN*Xes that ship libpcap might have a problem, especially if they > have to support third-party closed-source binaries. > > So, at minimum, we should continue to export it on UN*X. > > And that might be an issue with Windows binaries as well; I suspect > WinDump, for example, imports eproto_db from WinPcap, as it's based on an > older version of tcpdump that imported it from libpcap. I'll leave it up > to you to determine whether introducing a possible binary incompatibility > between WinPcap and Npcap is an issue. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Add WinPcap specific functions like pcap_open() to libpcap on Windows for binary compatibility
Hi Guy, On Tue, Jun 28, 2016 at 10:10 AM, Guy Harris wrote: > On Jun 27, 2016, at 11:22 PM, Yang Luo wrote: > > > So my thought is we need to add back those functions to libpcap on > Windows, the related source code files are remote-ext.h, pcap-new.c, etc, > which don't exist in libpcap. So are we OK with this? > > I am not OK with any solution that reintroduces the "pcap_md" structure. > OK. I have submitted a new PR: https://github.com/the-tcpdump-group/libpcap/pull/512. It moved the "pcap_md" structure to "pcap-remote.c". As "pcap-win32.c" already defined a priv structure of "pcap_win" type. So I put the "pcap_md" structure right after "pcap_win". I hope this arrangement is appropriate? > > The way libpcap works, and will continue to work, is that the pcap_t > structure has a "void *" member called "priv". Each pcap-XXX.c file > defines, internally, its own private data structure, allocates such a > structure, and sets "priv" to point to that structure. > > The code that captures remotely with rpcap must do this for all the > information it needs. > > Doing remote capture in an acceptable fashion, even if we don't generalize > it (as I intend to do in the future) to support multiple modules for > multiple protocols in addition to rpcap, is going to require significant > changes to the WinPcap remote-capture code. I know the remote capture is only workable for Windows now. This is the first step. You can generalize it to UN*X in the future version:) > You might have to, for now, maintain a temporary fork of the current > libpcap code, and remove your local changes once I've added an rpcap client > module to it. I think we first need to integrate all WinPcap existing features into libpcap, make them work at least on Windows, then generalize it to all platforms by adding an rpcap client like what you said. Cheers, Yang ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] About libpcap version display on Windows
Hi list, The current libpcap on Windows shows the version string in the "About Wireshark" window as ( https://github.com/the-tcpdump-group/libpcap/blob/master/pcap.c#L2118-L2123 ): with WinPcap version 4.0 (packet.dll version 0.07), based on libpcap version 1.x.y For latest Npcap 0.07 r17, it shows: with Npcap version 0.07, based on WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b (20091008) I think the expected result can be: with Npcap version 0.07, based on libpcap version 1.x.y 1) "WinPcap" string is hard-coded in pcap.c. So I think we can add the "Npcap" version into the libpcap repo? I'm also OK if you want to add “based on WinPcap version 4.1.3” behind the Npcap version. 2) It shows "libpcap version 1.x.y" instead of "1.7.4". Is this a bug? I think it's better to show "1.7.4"? Cheers, Yang ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
