LabVIEW
Ethernet sniffer with FPGA
Any FPGA code or idea would be appreciated.
Thank
L.D.MESU73 wrote:
Does anyone have code to receive Ethernet trames with FPGA decoder? (like the code on DevZone which includes code for reading and writing RS-232 data.) I would like to build a fast Ethernet sniffer and data decoderAny FPGA code or idea would be appreciated.
Thank
Excellent learning project! *
Please clarify.
Sniff the traffic of the ethernet port or use I/O lines to monitor packets?
Ethernet port will only be possible if you can access the driver level of the ethernet port and use Promicuous mode to capture the recieved frames. You will really need NI cooperation if you want this.
Port I/O will actually be easier I would think... if FPGA was fast enough... maybe for 10-based-T ... what is the top end sample time on FPGA ... today? 
Ben
* Back in about 1988, Robert J Schmalstieg (formally with DEC, acquired by Compaq and now with HP Network Support) wrote in VAX-Macro an application that ran on a VAX and would do what an LAN-Analyzer would do. He really wanted this functionality since there were only about (3) LAN-Analyzers available for the East Coast (Networks were so new that analyzers were very pricey!) So he found a hook into the driver for the network adapter that would put the adapter in promiscuous mode. Promiscuous mode would bypass the address and protocol checks normally performed by the hardware to toss or re-direct recieved frames.
We teamed up and started meeting on Thursday nights (we had to meet in person since there was no net avaiable for hob-knobbing) and worked as team to develop a multi-threaded application along with a Kernal mode routine that would service the interupt, apply simple filter before queing the packet to the disk routine. The file writting routine monitored the packet queue (we had to write our own que of course) and wrote it to disk. "Many a case of beer and lage pizza were deveoted to the good of programming those nights I'll tel you".
After about 4-5 months of developing in our spare time gave us the oppertunity to test the acquisition and filtering functions on a real network. We started by filtering on LAT (Local Area Transport, used to serve remote serial ports to a mainframe) and started seeing the text being typed by one of our managers. Our jaws dropped and we looked at each other when I beleive it was him (Robert Schmalstieg) that said "we could get real sneaky with this!". At that time we decided the program should be called "Sniffer.exe" and the data file would be named Olfactory.dat". THe post processing utility that would format "Olfactory.dat into "Olfactory.txt" was latter named Snicode.exe (Sniffer Decode).
In the course of developing Sniffer I learned a lot of things, some of which I use every day (inter-thread comm using queues ) and others that are useful only for answer "out-there" questions like this one. If you use the approach of hooking into the existing ethernet post, you will learn alot about what it takes to cooperate with NI and how to use their hooks and back-doors. None of this knowledge will transport very well to other environments.
Taking the I/O approach you are going to learn ethernet and the protocols that ride on it to a greater extent. What you will learn will apply as long as you are dealing with an ethernet device. The protocols that ride on ethernet are also implemented over other networks topologies as well.
Another plus for the I/O approach. There is no limit of what you can do with it! The "Promiscuous Mode" approach will not let you capture corrupted packets. Packet framing is handled by the hardware and an ill formed packet is concidered a collision or coruption and is tossed (when last I looked).
