Network Packet Capture Options

[bogathc1]

I have a 3rd party DLL that implements a custom communications middleware ontop of Ethernet. At the moment, it is using a network packet capture library to get access the frames so that it utilizes a custom ethernet stack, rather than opening a raw socket directly and using the host OS stack. Is there a network packet capture library for the Pharlap realtime systems? If we were to change the 3rd part DLL to access the socket and Pharlap's network stack, what limitations are posed by trying to do this in a compiled model using the model framework as opposed to a custom device?

[luda.mattski]

Hi bogathc1,

Admittedly most of what you're trying to do is over my head, but I know that Phar Lap systems can utilize Winsock API calls to dig into the ethernet stack.  I also found a similar post which may describe some options in a bit more detail:  https://forums.ni.com/t5/LabVIEW/How-to-Write-amp-Transmit-Ethernet-Frames/td-p/1564130

VeriStand has a lot of built-in TCP channels and there are existing custom devices on our GitHub repo for VeriStand that support many different communication protocols.  Have you looked there to see if any of the previously-created devices fit your application closely enough to use as a starting point?  

[Eric.M]

A small warning about Winsock. PharLap implementation of the sockets indeed uses winsock, but the functions and features can slightly differ from Windows, as NI modified it to fit the PharLap OS. It is undocumented and unsupported, so really the best options are to use the built-in primitives that LabVIEW offers. Anything else would slip off NI's radar if you experience weird behaviors.