MJ - I am implementing a binding to WinPcap. Currently the extension can open network interfaces and dump files, receive packets and apply filters. It is functional enough to implement a tcpdump[1] clone. Things to be done are cleanup of the code, testing on different Windows platforms and implementing packet transmission functionality. Project is hosted at [2].DD - I noticed that it is currently not possible to determine the source/destination IP's and ports per every packet received, would it be possible to implement such functionality?MJ - Extraction of source and destination IP has been added in v0.4. This is not very robust, but should work fine for 'normal' IPv4 packets. I am not sure if I will add anything else because I don't see the use in rewriting something as ethereal.DD - The reason I asked for this feature, is that jpcap had a lot implemented. Ofcourse, when using raw packets it is fairly simple to code myself. Anyway, the IP address functionality is welcome, the source and destination ports need code on the protocol level (TCP/UDP). And it is understandable that you want to leave that part to the end user.[Guest] I'm new in Tcl and would like use the wpcap but I need packet transmission functionality for my project. Is it possible to implement this function in wpcap0.4? Would you do that? Thank you.MJ - Send is implemented in release 0.5 downloadable from location mentioned above. Note that it is the programmers responsibilty to make sure the packet is correctly formatted and encoded for the device that is opened. You will probably want to use binary format to generate the packet.Because of the dual send/recv functionality that is implemented now, it seems like a good time to rewrite the package using Tcl channels to make concurrency more natural. This will remain on the Todo list for a while.[Guest] Thank you for the fast answer, it works fine!!!PataElmo - MJ, Could you explain your build environment for the source. Or just compile a DLL for me? I just need to change your code so that the timeout is infinite, or change 1000 to 0 on line 240 of tclwcap.c. Thank you for providing this wrapper it has made low level ethernet communication easy. My only problem is I have to wait 1 second for each response. Thanks againMJ - I use the MinGW tools to build this extension. I haven't have this environment set-up now, but you can get it yourself as described on [3]. Note that the most elegant way would be to make the timeout an (optional) part when creating a new handler.PataElmo - I managed to get this working with Visual Studio Express in the VS command prompt. Probably not the best way, but it worked. I actually found that my issue was not the timeout, it was that I needed to set pcap_setmintocopy() to my smallest complete packet size. I also switched to opening with pcap_open_live() but i'm not sure if that changed anything. If you'd like I can make this an optional argument and post it back to SVN, or send you a diff file so you can do it as well. Thanks for the help and for starting this project!MJ - pcap_open includes the functionallity of pcap_open_live. I know pcap_open can also open trace files to replay, I am not sure about pcap_open_live. If you would like to have this included can you log a bug or RFE at sourceforge?Roadmap
- Implement functionality with channels for better usability in GUI apps. This will have a large impact on how to use the library. (will be 0.7)
- Add procs to determine the MAC (done) and IP address from the open device handle.
Other references:
- WinPcap: The Windows Packet Capture Library[4]
- WinDump: tcpdump for Windows[5]
- Relationship of WPCAP.DLL and PACKET.DLL[6]
- WinPcap Brings Unix Network Tools to Windows[7]