Unleash Networks Blog

One of the most used features of Unbrowse SNMP is the passive SNMP trap receiver. The trap receiver can listen to SNMP trap activity using any of the following three options.

• On UDP Port 162 (this is the classic mode)
• Via Windows Raw Sockets
• Via Winpcap

When running Unbrowse SNMP on Windows Vista, you may encounter the following message when attempting to listen to SNMP traps using the Winpcap library.

This message means that Unbrowse SNMP is not able to load the Winpcap driver service using the current users credentials. Unfortunately, running Unbrowse SNMP as administrator does not fix the problem.

The work around is :

• Open a command prompt as administrator (Start->All Programs->Accessories -> Right click on Command Prompt and Run as administrator)
• Type “net start npf” This loads the driver used by Winpcap.
• Exit

Now, Unbrowse SNMP can listen to traps without further issues.

Note : This only needs to be done once after you restart the machine.

 

A new version of Unbrowse SNMP is available (Build 1234).

You can get it from the downloads page.

Release highlights :

• Handle SNMP devices (Cisco) which include special characters like CR and LF as part of printable Octet Strings. When such characters are seen Unbrowse will replace them with {CR} {LF} in the MIB Walker.
• Fix a bug while issuing SNMP SET commands for binary data (Eg, Hex: ff ff ff). You can now include spaces for readability.
• Allow copying the output of the MIB compiler window.
• Allow clearing the MIB compiler window. 
• Various minor fixes

Get it now !

Unleash Networks is a member of the Intel Software Partner Program. Thanks to the program we have access to a powerful tool for measuring multi core performance of the new Trisul Open Source Network Metering and Forensics tool. I installed the 45-day eval of the Intel Thread Profiler for Windows with the Linux Data Collector.
I then measured Trisul‘s packet processing performance on a dual core system. The results are at the Project Wiki Site.

From my various experiments with threading packet processing, I am leaning towards these conclusions
1. Getting packet processing right on multiple cores is hard.

2. Traditional threading systems seem to be very difficult to get right. Given the volume of tokens (packets), it is easy to incur too much synchronization overhead or severely impact cache performance.

3. Task based approaches like the Intel Threading Building Blocks appear more attractive.

The next major task would be to create a quick prototype application using the Intel TBB library and revisit the measurements.

–

Trisul news :

I got some email pointing out that the DEB and RPM packages were missing. Sorry, they will be up shortly. The packager is broken.
There are many packet processing tools like Ntop, Snort, Sancp, Argus, etc. Trisul will hopefully find a niche because of its ability to reduce traffic data to a SQL database and its extensible architecture that allows other functions to be plugged in. (Documentation about the architecture is not yet available but see the sysplugs directory in the source code)