Can LabView be used to create applications to sniff ethernet traffic?

[JGG]

I am interested in using Labview to do what a Fluke or similar network analyzer might do to detect devices, sniff traffic, check for packet and electrical errors, etc.

It seems to me that LabView should be able to read data from a local NIC, digitally or otherwise, like any other IO device. Since I'm pretty novice at this, could someone kindly enlighten me?

Thanks,

JGG

[Ben]

Hi JGG,

A similar question was asked recently. See below.

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000001420000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0


Ben

[JGG]

Hi Ben,

The original writer indicated he couldn't answer the question directly and the application he wrote is 15 years dated.

I read about the C based API in the follow up post and it might be worth exploring in my very spare time unless someone in the group has actually worked with the DLL's and can speak to their ease and practicality of use.

What I am asking, is what is built natively into Labview that provides this functionality (or alternatively a 3rd party plug-in that takes advantage of the Labview UI without requiring a lot of low level coding.)

So let me re-phrase my original question to be more specific:

Are there any functions built natively into Labview (or as a 3rd party add-in) that will provide low and high level packet detection
to detect WAN/LAN devices, sniff traffic, check for packet and electrical errors, etc., directly from an on board NIC?

Regards,

JGG

[Ben]

Hi JGG,

I was the 15 year old app guy.

NO standard NIC card will tell you anything about electrical interference.

It is only after the packet checksum varifies that any else can be done. Electrical interference (bad enough to affect data) will cause a checksum error, along with collisions.

Even the ability to look at corrupted frames requires special hardware.

Ben

[JGG]

Dear Old Timer,

(Just kidding...) I wasn't thinking along the lines of elecrical interference. That would presume that NICs are analog devices (and I have no illusions of that.) I expect that the best anyone can expect is for the NIC to trigger a bit whenever the line voltage exceeds a min. threshold voltage.

So we throw the NIC into promiscuous mode and detect raw bits. Thus bit capture, packet assembly/disassembly and manipulation with LabView was more along the lines of my interest.

Any thoughts?

Regards,

JGG

[Rob Cole]

I built a protocol analyzer for Arcnet a year or so ago. It sounds like this is the kind of thing that you're looking for. Something that would throw the NIC into promiscuous mode and then display: type of packet, who sent it, who it's to and the data being sent.

I can't send you my Arcnet Protocol analyzer to look at since it's specific to our proprietary protocol, but it is easy to build. I have a protocol file on disk that is loaded into an array and any incoming packets are decoded according to the data in the array (I hope this isn't too confusing of an explanation). It took more time to type in the protocol definition file than to write the program.

The only slight glitch is trying to get Windoze to ignore the network card so you can set up your own
handling of the data.

Rob

[jcop]

Could you elaborate on how you started? I am using LabVIEW 6i and don't see any easy place to start finding the NIC, much less displaying traffic or parsing packets received.

[TRLJr]

I going to be more specific in this question.  I have a NIC that to xp looks like an Ethernet NIC and shows up as a network connection, exept that the other side isn't Ethernet, it is BACnet ms/tp.  The "NIC" has an Ethernet address, is connected, and recieving data.  I don't need it to be decoded simply input and recorded.

The question is: How do I access that data stream w/Labview?

[Charlie S.]

Hi TRLJr,

I am not personally familiar witih BACnet, but I did a little research. It looks like there are 3rd parties out there that provide OPC servers for BACnet. This would be the easiest way to communicate with your device. LabVIEW can act an OPC client through datasocket or with Shared Variables using the Datalogging and Supervisory Control Module (DSC). If you're looking for something more low-level, you might try some driver-level calls, although I'm not sure what to call to be honest. I don't think the regular TCP/IP VI's in LabVIEW will work unless BACnet uses TCP.

Just some thoughts,