Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Oh, just for the records, the version 0.09 should work on ActivePerl, and you can install the PPM from Randy Kobes' repositories. See []

    (I know, it's ActivePerl, not Cygwin; but Cygwin is a little tough to get right, as it partially relies on Win32 to use WinPcap.)

    Close the world. txEn eht nepO
    • Hi, thanks for commenting, Sébastien. No, I am afraid there is nothing sufficiently different in v0.09 that it can work under Cygwin. It doesn't. Two things stand out in the overview of WinPcap and Net::Pcap that I've gotten over the last couple of days. One is that nowhere that I have seen is anyone claiming that WinPcap is software that has been ported to Cygwin. The clear claim is that WinPcap "can be built using cygwin", and I've established, by looking hard at the build infrastructu

      • Ok, I took some time and used a Windows system with a Cygwin to test Net::Pcap myself. I have to admit that it's far from being obvious, but all this comes from the fact that Cygwin pretends to be a Unix system (it internally defines itself as a Unix, offers the Unix API, and defines the preprocessor macro _unix). But in fact, it is really bound by the limitations of the Win32 system on which it runs. It usually works in an quite acceptable manner, but in some corner cases can lead to strange behaviour because it can't work exactly like a Unix system, and yet doesn't behave like a Win32 system. A example I recently outlined in Perl5 Porters [] is the behaviour of unlink(), which is neither like Unix nor Win32.

        I usually sum up the Cygwin problem in French by saying that it has "le cul entre deux chaises" (its ass between two chairs).

        That said, Jean-Louis Morel assured me that Net::Pcap worked under Cygwin. His web page is not yet out of date as I haven't integrated all the changes he made for the Windows (ActiveState + Cygwin) version of Net::Pcap (the current CPAN version still miss several Windows specific functions).

        So let's examine the problem. The WinPcap library is, as you said, a Win32 library, but the developer kit includes several versions. It also includes several headers. Indeed, some of the headers included in the developer kit contains the Win32 definitions of the network API, which directly clashes with the ones defined in Cygwin /usr/include. The clash happens because Cygwin's packet.h tests for and defines a _PACKET_H macro while the WinPcap one tests for and defines a PACKET_H macro.

        Ok, so the headers are the problem. So why not just copy the necessary headers to compile Net::Pcap in /usr/include? (I'm saying this from memory, I don't have the Windows machine at hand)

        cp Headers/pcap* /usr/include

        Now these headers will be in the default search path, and we just have to give the location of the libraries:

        perl Makefile.PL LIBS="-L$WIN32LIB -lwpcap"

        Et voilà !

        I agree this is twisted, but with this, I was able to compile and run a few tests. I couldn't run the whole test suite because lookupdev() returned by default what seems to be the modem device.. which is very unlikely to see any traffic at all as I am connected with an Ethernet interface like any modern workstation. So there's a need here for handling this special case, but at least, I can confirm myself that Net::Pcap compiles and can be run under Cygwin.

        And I didn't even ask Jean-Louis for help, so it wasn't that hard ;-)

        That said, I agree that Jean-Louis probably overlooked the fact that his system has already been configured to handle this. Maybe he just also copied some of the libs in /usr/lib (I tried that once but it didn't work, but I may have forgot one of them). So I'll update the documentation and the help message to help Cygwin users.

        Please try this on you system and confirm that it also works for you. If that's the case, then you owe me a bar of chocolate ;-)

        Close the world. txEn eht nepO
        • Hello again, Sébastien. No good news, and no bar of chocolate, I'm afraid.

          The technique you cited above is unacceptable to me exactly as given, because the contents of /usr/include are managed by the Cygwin package management system. I under no circumstances will manually copy files into that directory as a matter of programmer / sysadmin discipline. The evils that can stem from that act are manifold, and include being unable to reproduce user errors reported by anyone who trie