Scapy crashes on Windows Vista with the "scapy version" pypcap

[scapy.20.elimis@…]

(For the record, I'm using Python 2.5.2, running on Windows Vista Home Edition).

I followed the installation guide for installing Scapy on Windows, including downloading and installing a special version of PyPcap? (supposedly because of bugs in PyPcap? preventing parts of Scapy from working).

Unfortunately, Scapy crashed every time I tried to sniff packets from my network (nothing fancy, just called "sniff(1) or some such). More specifically, when I did this, my Python.exe crashed (no convenient error message, unfortunately).

I just tried installing the regular, non-patched version of PyPcap?, and while I haven't messed around with Scapy too much (I'm a new user anyway), it is now at least allowing me to sniff my network without crashing.

Note: Before installing the original pypcap, I tried doing: import pcap p = pcap.pcap() p.setfiler("icmp")

This alone (without importing Scapy or anything) caused Python to crash. Of course, after installing the regular pypcap, it started working fine.

Anyways, hope the description was clear, I should be reachable at my email if anybody needs any further info.

DASH

[Dirk Loss]

Thank you for the detailed bug report. Several Vista-users had emailed me about these crashes before and it always seemed like a pypcap problem, but with your help the problem is now narrowed down to the special pypcap version I compiled.

I don't have any Vista system for testing, so debugging and fixing this is hard for me. I'll see if can get my hands on a Vista test system over the next weeks.

As far as I know, this only affects Vista. Scapy-win works fine under Windows XP.

Dirk

[Brad]

Replying to Dirk Loss:

it always seemed like a pypcap problem, but with your help the problem is now narrowed down to the special pypcap version I compiled.

I've been having the same problems as the original report, only with slightly different functions. Hopefully I can help you narrow it down.

My first crash occurred when I tried to use send() to send a packet (I tried ones that had IP with UDP payload, TCP payload, and no payload at all). By inserting debug statements in Scapy's code I narrowed it down to a call inside class L3dnetSocket(SuperSocket), in def send(self, x). The crash came from the line

sx = str(Ether()/x)

With a little experimentation I found that calling str() on the composition of an Ether() object with its "dst" field unset, with any other object, causes the crash. For example, these worked fine:

str(Ether())
str(Ether(dst="00:11:22:33:44:55")/IP())

But this would crash:

str(Ether()/IP())

Attaching OllyDbg? to the process, I found it to be an access violation on apparently random memory addresses. It looks like there's a problem with a call to free(). The top of the call stack at the time of the crash looked like this:

Address    Stack      Procedure / arguments                 Called from                   Frame
0026E5B0   7787F676   ntdll.7787F2F1                        ntdll.7787F671                0026E5AC
0026E6A8   7787F285   ? ntdll.7787F5E5                      ntdll.7787F280                0026E6A4
0026E6C4   76203621   ? ntdll.RtlFreeHeap                   kernel32.7620361B             0026E6C0
0026E6D8   7C34218A   ? kernel32.HeapFree                   MSVCR71.7C342184              0026E6D4
0026E6DC   002D0000     hHeap = 002D0000
0026E6E0   00000000     Flags = 0
0026E6E4   00B41678     pMemory = 00B41678
0026E720   62B82578   ? <JMP.&msvcr71.free>                 pcap.62B82573                 0026E71C
0026E724   00B41678     block = 00B41678
0026E760   1E08F24B   Includes pcap.62B82578                python25.1E08F249             0026E75C

I looked at the code for pypcap, and I found only three calls to free(). Two of them are in def __dealloc__(self), and one is in def setfilter(self, value, optimize=1). The original bug report noted a crash caused by setfilter, and my crashes could have been caused by the automatic destruction of pcap objects created by __str__ or other functions.

I was hoping to hack together a solution myself, but this is about as far as my understanding goes. I hope you get a chance to figure it out and maybe release a new patched version for Vista. In the meantime, I can corroborate that the unpatched pypcap does not produce these crashes, and it seems to work so far.

As far as I know, this only affects Vista. Scapy-win works fine under Windows XP.

I can also corroborate this, having enjoyed Scapy for quite a while on my XP machine. Thank you for your work. :)

[Dirk Loss]

I have finally got around to install a Windows 7 RC virtual machine and can now reproduce those bugs myself.

Brad, thank you very much for your detailed and helpful analysis!

So let me summarize our current findings: My patched pcap module from pcap-1.1-scapy.win32-py2.5.exe lets Python crash on Vista and Windows 7 with an access violation when free() is called. This bug can be easily triggered by setting a BPF filter or by deallocating a pcap object:

>>> import pcap; pc = pcap.pcap()
>>> pc.setfilter("icmp")

>>> import pcap; pc = pcap.pcap()
>>> del(pc)

On the other hand the official pcap module from  http://pypcap.googlecode.com/files/pcap-1.1.win32-py2.5.exe works fine.

I think the problem is not my patch itself, because I get the same crashes if I just compile pcap from source -- without any modifications. So there must be something wrong in my build process for pypcap. Currently I am using:

• pypcap-1.1.tar.gz
• MinGW-5.1.4
• Pyrex-0.9.8.5.tar.gz
• WpdPack?_4_0_2.zip

--Dirk

[anonymous]

Just for testing I have built a pypcap version with all free() calls commented out. Of course this leaks memory, so only use it for testing:

 http://dirk-loss.de/scapy/pcap-1.1-scapy-20090718-memleak.win32-py2.5.exe

It seems to work for me. No crashes anymore.

While this dirty hack might already be enough for some users, we should try to fix the underlying issue of course. I'll have a deeper look at this, but I am not a C programmer. Any help or ideas would be appreciated.

Dirk

[anonymous]

This new pypcap version should fix the problem:

 http://dirk-loss.de/scapy/pcap-1.1-scapy-20090719.win32-py25.exe

Please uninstall the old pypcap version before installing the new one. You might need Admin privileges so that the installer can write to the registry.

I have successfully tested this on Windows 7 RC and verified that it still works on Windows XP. Please let me know if it works for you or if there still are problems.

Background:

The problem was that my pypcap build used two different C libraries, msvcrt.dll and msvcr71.dll. The strdup() was taken from msvcrt.dll, but free() was taken from msvcr71.dll. Googling for "strdup free msvcrt msvcr71 mingw" shows that other have had this problem, too.

I just removed the "-lmsvcr71" parameter from the MinGW gcc.exe command line and now pcap.pyd does not depend on msvcr71.dll anymore. Both strdup() and free() seem to be taken from msvcrt.dll now so we do not confuse the memory manager any longer.

[Dirk Loss]

The installer at http://www.secdev.org/projects/scapy/files/pcap-1.1-scapy.win32-py2.5.exe has been updated to include the fix. In the new version pcap.__version__ should show a date of 2009-07-20 or later.

Regards

Dirk