You must be a MyPeek member to download our extensibility solutions. Click here to learn more about the benefits of membership and find out how to sign up for free.
![](/images/icons/exclamation.png)
If you are already a member please login to download the file. If you are not a member, register now for free.
Submitted By : Chris Bloom
Downloaded : 559 Times
Rating : Not Yet Rated
View Comments ()
With the Geiger Plug-in, you can listen to your network. There are all kinds of possibilities here, and the Geiger Plug-in is just a simple demonstration.The Geiger Plug-in has two modes. The default mode is to beep once a second, if any packets were capture during that second. The more packets, the higher the frequency.
The other mode is to beep every time a packet is captured. In this mode, the frequency increases for larger packets. The "beep per packet" can be enabled from the Options->Analysis Modules->Geiger Counter Option Dialog.
![](/files/mypeek_esm_images/geiger_options.jpg)
It is important to keep in mind that in "per packet" mode, each beep takes one millisecond, which on high band width networks, could result in lost packets.
The most obvious application for the Geiger Plug-in is hands off analysis, where you are doing something, like driving, and cannot sit there and stare at a computer screen.
Developing your own Geiger Counter
OmniPeek has a network geiger counter built-in to the Signal Strength Tab. It is fun. If you did not know about it already, you should give it a try.
Geiger counters may be considered academic or even art, which is fine and maybe true, but if certain network events are given the right audio identifiers, listening to the network can be a useful way to stay informed about certain network events using your sense of hearing.
What I like to do is come up with different algorithms to convert network traffic and statistics in Peek to audio. And because it is so easy to create geiger counter plugins with the plugin wizard, I thought I would share with you some geiger counter ideas that you can try.
First, use the plugin wizard to create a geiger counter plugin. Call it what you want, I called mine Geiger. Next, go to CGeigerContext::OnProcessPacket(). This is where you will add code to produce audio for each packet that is captured. Digging through the packets is also a fun way to experiment with the packet helper functions provided by the plugin wizard framework and to build your own library of packet mining functions as well.
To produce audio I use the system Beep() function. Beep() does not produce the prettiest sound but it easy to use. There are other functions you could use to produce audio, including functions that will play .wav files. This is something I have thought about it. Making and playing certain .wav files could really take this idea to the next level.
But anyway, back to today. The Beep() takes a frequency and a duration. The frequency range is the parameter I use to represent the network events. I leave duration at 1 millisecond because you have to keep in mind that the OnProcessPacket() function is called on the capture thread and we certainly want to minimize any impact we have on that. Otherwise, we may drop packets while we are beeping.
Now, you could get fancy and create a thread that calls the Beep() for you. This would allow your beeps to be of any duration without worrying about the capture thread. Oooh, you could also have a pool of threads so that some number of beeps with varying durations could actually overlap. Hmm, I had not thought of that before. So many ideas, so little time. If somebody out there tries this, please let me know how it goes.
To summarize the threaded beeper model, the beeper thread would wait on a Win32 Event which you would signal anytime you wanted it to call Beep(). You would also set up a queue of beep messages that had the frequency and duration you wanted for each call to Beep(). This is actually a common model. Many types applications use a thread with messages like this in order to offload processing from the capture thread. I feel a new article coming on about that topic. But that is another day.
In my simple, single threaded plugin, I just leave the duration at 1ms. The following is a sample algorithm I thought sounded pretty good.
int CGeigerContext::OnProcessPacket( PluginProcessPacketParam* ioParams ) { DWORD dwFreq = GET_PSID(ioParams->fProtoSpecMatched) / 4; for (DWORD i=0; i < 6; i++) { dwFreq += ioParams->fPacketData[i]; } dwFreq *= 10; if (dwFreq > ioParams->fPacket->fPacketLength) { if (dwFreq - ioParams->fPacket->fPacketLength > 37) { dwFreq -= ioParams->fPacket->fPacketLength / 2; } } Beep( dwFreq, 1 ); return PLUGIN_RESULT_SUCCESS; }
I won't go into the details of this algorithm because it does not really matter. It is just what I ended up with after experimenting for a while. There are so many possibilities though. Here are a few:
* Signal strength for wireless packets.
* Distinct sounds for different protocols
* Distinct sounds for error packets
* Distinct sounds for certain nodes
* Distinct sounds for top talkers
* Distinct sounds for first timers
* etc....
And then it gets really interesting to make the frequencies and durations for these sounds options that the user can adjust.
Now that you have read this far, I will tell you how to create a custom geiger counter without having to create a new plug-in. PowerBar
That is all for now. All comments are welcome, and let us know if you have any requests for articles on other Peek development topics.
History
Version 1 9/13/7007
- Posted to WPDN