LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

WinPCAP for LabView v 0.1 alpha

Changes:

* Now compartmentalized into a library (*.llb) for easier use.
* Added packet writing using pcap_sendpacket. You can now send RAW ethernet (useful for MAC and IP spoofing) from LabView
* Pretty icons
* Simplified demo *.vi, so that memory allocation occurs in the library components
* More reliability testing (:note: "read" now only grabs one packet at a time off the buffer, so you may have to "read" several times to get to the last packet.)

Future Planned Improvements:

* Rolfk's suggestions for memory allocation in C to improve performance.
* Fix bug -- pressing "release all" when device has already been released can cause a lock-up.

Hope you find it useful. It's been handy for me recently.

-James
Message 11 of 36
(7,049 Views)
Carlos-

I haven't had the opportunity to use CVI, but I imagine if you are trying to create DLLs (or only compiled C objects) with Windows, that you might benefit from MinGW.

http://www.mingw.org/

MinGW is a Windows port of the GCC toolset. It requires no special functionality to run what you build under MinGW on any Windows box.

Is that what you were looking for?

Regards,
-James
Message 12 of 36
(7,049 Views)
Hello, James

No, not exactly.  I was looking for total independence from other compilers but from the CVI one.  If I used MinGW, I would encapsulate winpcap exactly as I do now with VC++.

Thank you very much
Carlos Arcediano del Amo
0 Kudos
Message 13 of 36
(7,035 Views)
Hello Carlos,

So you mentioned that when you call your DLL in CVI, it looks for certain header files.  You also mentioned that these header files are part of Visual Studio.  Well the header files are probably located somewhere on your hard drive.  So, it shouldn't be a problem for CVI to find them if you add the header files to your CVI project.

Even if your DLL depends on the Windows SDK, CVI can called into these DLLs and static libraries.  What you need to do to call the DLL in CVI is to:
  • Include the DLL on your CVI project folder
  • Include the static library for the DLL in the CVI project
  • Include the header file for the DLL in the CVI project
Those three steps should correct any linking errors you see in your application.  If not, could you be more specific as to the error you are receiving, and what you are including in your CVI project?

Thanks
Message 14 of 36
(7,013 Views)


@Wendy L wrote:
Hello Carlos,

So you mentioned that when you call your DLL in CVI, it looks for certain header files.  You also mentioned that these header files are part of Visual Studio.  Well the header files are probably located somewhere on your hard drive.  So, it shouldn't be a problem for CVI to find them if you add the header files to your CVI project.

Even if your DLL depends on the Windows SDK, CVI can called into these DLLs and static libraries.  What you need to do to call the DLL in CVI is to:
  • Include the DLL on your CVI project folder
  • Include the static library for the DLL in the CVI project
  • Include the header file for the DLL in the CVI project
Those three steps should correct any linking errors you see in your application.  If not, could you be more specific as to the error you are receiving, and what you are including in your CVI project?

Thanks


I think what he wanted to do is to compile the wrapper DLL in CVI too. However the wcap headers or the wrapper DLL depends on certain C runtime functions that are declared in some Visual C header file. I haven't looked at the exact file but unless it is a standard ANSI C header file, CVI won't come with that out of the box.

Of course if you have Visual Studio installed you can always add its include directory to the include directories of your CVI project but without Visual Studio you have to find another solution. The FDS of CVI does come with a more or less full Windows Platform SDK so installing that should help unless it is one of those obscure headers that only come with Visual C itself. But then I would be surprised that an Open Source project like WinPCAP makes use of it. It would create all kinds of version hassles for the project maintainers too, and tie the compilation of it to a particular compiler.

He could also download the Windows plattform SDK and install it, but it will probably not (if didn't in the past) allow to compile code out of the box with CVI since some of the headers and macros are adapted for CVI in the SDK distributed with CVI.

Rolf Kalbermatter

Message Edited by rolfk on 05-18-2006 09:00 AM

Rolf Kalbermatter
My Blog
Message 15 of 36
(7,012 Views)
Hello everybody

Maybe the solution is the hardest one: tracing the header definitions and the function calls and change this directives by the ones used by CVI, more or less like this:

#ifdef _CVI_   //predefined macro in CVI
#include <cvi_header_file.h>   //the equivalent header file used in CVI
#else
#include <fcntl.h>   //I can remember only this file
#endif

An other easier solution?

See you
Carlos Arcediano del Amo
0 Kudos
Message 16 of 36
(6,989 Views)
James,
 
I notice that your call library functions are configured to run in the UI thread.  Is this necessary (maybe the WinPcap functions are not thread-safe)?
 
I have an application where we need to continuously collect "raw" ethernet packets from some proprietary hardware.  Your VI's look like they will be a big help.
 
Rich
0 Kudos
Message 17 of 36
(6,963 Views)

RLD,

Apologies for the late reply. WinPCap is thread safe. I currently don't return some of the PCap information, and it is retained in user memory, like you noted. I believe it's not necessary to keep anything in memory, if the handle information is returned from the DLL to LabView. It's only a little extra work.

I'm planning to do an update on my next block of free time. I'll try exporting those handles, if that'll help you, when I sit down to do it.

Glad it's helping out. Thanks for using it!

Message 18 of 36
(6,924 Views)
James,
 
I've finally had the opportunity to experiment with your version "WinPCap Labview 0_6.zip".  I notice a couple of things.  It looks like pcap-finder.vi must be run before running pcap-open.vi, even if you already know what the device number is.  Runing pcap-read.vi in a loop has a limited cycle time?  I would like to capture a stream of packets which arrive at a rate approaching 220 Samples per sec.  Is WinPcap limited in it's speed of response?
 
Rich
0 Kudos
Message 19 of 36
(6,770 Views)
Dear all,

I want to know that can I use the Labview with Wincap (Packet sniffer) for graphical analysis in real time. If yes, then anyone can tell me that can we see all the information like frame length, how many packets are coming etc in graphically form.

If not, then what would be the reason behind this ?

I am waiting yours answer.

regards

Maani

0 Kudos
Message 20 of 36
(5,945 Views)