[Winpcap-users] While testing Gianlucas winpcap3.1[prerelease]...
Gianluca Varenni
gianluca.varenni at cacetech.com
Tue Aug 2 18:16:04 GMT 2005
Why are using "CoUninitialize()" just after InitPcap??
Have a nice day
GV
----- Original Message -----
From: "Marc Wetzel" <mwse at gmx.de>
To: <winpcap-users at winpcap.org>
Sent: Tuesday, August 02, 2005 3:36 AM
Subject: Re: [Winpcap-users] While testing Gianlucas
winpcap3.1[prerelease]...
>I wrote a little test application
>
> First version just calls ThreadProc() (without using threads),
> the second version uses BeginThread() to use this function as the
> threadproc.
>
> Please see my findings:
>
> Winpcap (prerelease) using Windows XP/latest SP
>
> SingleThreaded version:
> - Works with and without using COINIT_APARTMENTTHREADED
> - mulitple calls to pcap_open() are successful (not tested if they
> actually receive packets)
>
>
> MultiThreaded version:
> - Works only with using COINIT_MULTITHREADED !!
> - it only works if I init COM _outside_ the thread.
> - mulitple calls (say multiple threads) to pcap_open() are NOT successful,
> the second call to pcap_open blocks until the first pcap_handle is closed
>
>
> Greetings
> /Marc
>
> --
> PS:
> snippet of my testcode:
> I only used it to test, while single-stepping through the code, so
> checking some resultcodes was omitted!
>
> FUNCTION ThreadProc(Thread: TThread): Integer;
> VAR
> ErrBuf : ARRAY[0..PCAP_ERRBUF_SIZE - 1] OF Char;
> FPcap : PPcap;
> FError : STRING;
> BEGIN
> FPcap := pcap_open('\Device\NPF_GenericDialupAdapter', 1600, 0, 30,
> NIL, ErrBuf);
> //FPcap := pcap_open('\Device\NPF_GenericNdisWanAdapter', 1600, 0, 30,
> NIL, ErrBuf);
> IF FPcap = NIL THEN
> BEGIN
> FError := ErrBuf;
> exit;
> END;
> IF assigned(Thread) THEN
> WHILE (true) DO
> sleep(1000);
>
> END;
>
> PROCEDURE TForm1.Button1Click(Sender: TObject);
> VAR
> FHandle : THandle;
> FThreadID : THandle;
> FHandle2 : THandle;
> FThreadID2 : THandle;
> res : LongInt;
> BEGIN
> InitPCAP; // Loadlibrary and function binding...
> CoUninitialize;
> //res:=CoInitializeEx(NIL, COINIT_APARTMENTTHREADED);
> res := CoInitializeEx(NIL, COINIT_MULTITHREADED);
> // Test-1 SingleThreaded
> // ThreadProc(nil);
> // ThreadProc(nil);
> // Test-2 MultiThreaded
> FHandle := BeginThread(NIL, 0, @ThreadProc, Pointer(Self),
> CREATE_SUSPENDED, FThreadID);
> ResumeThread(FHandle);
> Sleep(5000);
> FHandle2 := BeginThread(NIL, 0, @ThreadProc, Pointer(Self),
> CREATE_SUSPENDED, FThreadID2);
> ResumeThread(FHandle2);
> END;
>
>
>
> Gianluca Varenni wrote:
>
>>
>> ----- Original Message ----- From: "Marc Wetzel" <mwse at gmx.de>
>> To: <winpcap-users at winpcap.org>
>> Sent: Monday, August 01, 2005 12:43 PM
>> Subject: Re: [Winpcap-users] While testing Gianlucas winpcap3.1
>> [prerelease]...
>>
>>
>>>
>>>>>
>>>>> But you might remember, that I had trouble using winpcap3.1.b4/WAN
>>>>> devices with Delphi,
>>>>> because of some kind of COM initialization problems.
>>>>> It only worked if I do a CoInitializeEx(NIL, COINIT_MULTITHREADED) at
>>>>> the very start of the code.
>>>>
>>>>
>>>>
>>>> I know. This is one of the biggest headaches I had with WinPcap and
>>>> NdisWan.
>>>>
>>> It really really only works if I set it to COINIT_MULTITHREADED (not the
>>> other way around).
>>
>>
>> Uhm, are you using Windows XP? If you are using the test dlls on my web
>> pages (i.e. the latest build of the dlls, in practice) every attempt to
>> open/list the wan adapters fails if COM has been initialized as
>> COINIT_MULTITHREADED *on the same thread*.
>>
>>
>>>
>>> I use winpcap the following way... maybe there is a problem with my
>>> code?
>>>
>>> in the main process I fetch the devices (pcap_findalldevs) to look if
>>> there is a WAN device.
>>> I such device is found I create a new thread and tell it to open the
>>> specific device (I found out in the main process)
>>> inside the thread I use pcap_open to open this device...
>>
>>
>> That's ok.
>>
>>>
>>> And I really have to initialize to COINIT_MULTITHREADED, get it going
>>> (in beta4)
>>> In beta4 this had nothing to do with pcap_findalldevs(). This just ever
>>> worked, regardless which
>>> ComThreadModel I choosed.
>>> The failure just happened on pcap_open()
>>
>>
>> In beta4, there were a series of bugs related to COM initialization
>> (coupled to a series of bugs in the MS NetMon
>> COM component for which I've put some patches only after 3.1beta4, i.e.
>> in the test DLLs on my web). These bugs caused a whole series of random
>> effects: application crashes, Wan adapters not listed....
>>
>>
>>>
>>> I just tested it again (this time I tried to use multiple threads
>>> opening NdisWanBh)
>>> And I found out, that my second call to pcap_open blocks until I close
>>> the first winpcap handle.
>>
>>
>> Wait, wait. NdisWanBh should NOT be listed by WinPcap. If it's listed, it
>> probably means that your WinPcap installation has something really weird.
>> Are you sure it's NdisWanBh??
>>
>>>
>>>
>>>
>>>>>
>>>>> #2:
>>>>> With the prerelease I have now other problems...
>>>>> If I use CoInitializeEx(NIL, COINIT_MULTITHREADED) I only see my
>>>>> Ethernet-Device (using pcap_findalldevs).
>>>>
>>>>
>>>>
>>>> This is correct. Basically, the NetMon COM component used by WinPcap to
>>>> capture from PPP does NOT work in the MULTITHREADED threading model on
>>>> Windows XP. As a consequence, that device is not listed *if* COM has
>>>> already been initialized with that threading model.
>>>>
>>>>
>>> Is there any official documentation to this? I didnt found anything on
>>> MSDN on this subject.
>>
>>
>> Nope. The MSDN documentation says almost *nothing* about the NetMon
>> component (and all its issues/bugs).
>>
>>>
>>>>
>>>>> And if I comment the CoInitializeEx call out, I see all devices as
>>>>> expected, but then it fails
>>>>> in the call to pcap_open() with the error message "The system cannot
>>>>> find the device" (just as before).
>>>>
>>>>
>>>>
>>>> Uhm, are you sure? I've thoroughly tested it without any problem on my
>>>> machine. Have you tried building a small C app (or one in the devpack)
>>>> and see if it works?
>>>>
>>>> If you don't initialize COM, winpcap initializes it with
>>>> CoInitialize(NULL) before opening the GenericDialupAdapter.
>>>>
>>> Delphi normally does not initialize COM. Only if needed (by using
>>> certain libraries, I dont use).
>>>
>>>>>
>>>>>
>>>>> Just an addendum:
>>>>> #3:
>>>>> Using CoInitializeEx(NIL, COINIT_MULTITHREADED) in a Com-Application
>>>>> is not possible,
>>>>> e.g. embedding the IE-ActiveX object will always fail. This means that
>>>>> having an application which uses
>>>>> both the IE-ActiveX and winpcap (sniffing on WAN devices) is not
>>>>> possible.
>>>>>
>>>>> Sniffing ethernet devices is not touched by this problem.
>>>>>
>>>>> Maybe I am completely wrong?
>>>>> Does anybody have a clue, or is this a bug?
>>>>
>>>>
>>>>
>>>> I think that's what I explained before. On Windows XP the MS NetMon COM
>>>> component does NOT support the MULTITHREADED threading model. At the
>>>> moment I haven't found an easy solution to this issue.
>>>>
>>>
>>> Gianluca,
>>> Is there maybe a newer release I can test against?
>>
>>
>> No. No further patches have been added to the dialup/NdisWan code. The
>> test dlls on my web area are the latest ones from that point of view.
>>
>> Have a nice day
>> GV
>>
>>>
>>>
>>> TIA
>>> /Marc
>>> _______________________________________________
>>> Winpcap-users mailing list
>>> Winpcap-users at winpcap.org
>>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>
>>
>> _______________________________________________
>> Winpcap-users mailing list
>> Winpcap-users at winpcap.org
>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
More information about the Winpcap-users
mailing list