On Jul 23, 2013, at 1:23 AM, "Sebastian Klein" <[email protected]> wrote:
> I didn't add new function pointers. I added it e.g. PacketOpenAdapter(). I > added an additional flag for the device and then the appropriate function is > called. Before libpcap had a "module" mechanism, with function pointers in the pcap_t, adding new devices to WinPcap by hacking PacketOpenAdapter(), as was done for AirPcap devices, might have been the way to do it. Now, however, using the function pointers is the best way to go; that's what was done for various additional devices on Linux and FreeBSD, and what was done for TurboCap devices on Windows. > Do you mean pcap_read_win32_npf() with the "read" routine? pcap_read_win32_npf() is *a* "read" routine; so are pcap_read_linux(), pcap_read_linux_mmap(), pcap_read_bpf(), pcap_read_dlpi(), and so on. You would have your own "read" routine for your device, which would be used instead of pcap_read_win32_npf(). > There I don't have any options to set a specific error massage; it can just > return -1 if an error occurs. If a "read" routine returns -1, it *must* set p->errmsg (or handle->errmsg or whatever the name of the variable for the "pcap_t *" is). Not doing so means applications will try to report as an error string whatever happens to be in the errmsg member of the pcap_t; that might be an earlier error, or might be uninitialized data - the latter would be *very* bad. _______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
