Free incoming and outgoing software for linux

Useful Traffic Accounting Dragon is a traffic accounter that actually gives useful information about traffic instead of stupidly counting incoming/outgoing packets.
Dragon accounts traffic by user, program and timestamp and puts this information into useful correlation.
Dragon is implemented as a Perl script for the backend, using /etc/passwd to automatically get information about user accounts, /proc/net/ to get information about open connections and /proc/ to get information about running processes and which processes currently use which network connection.
All this information can be combined so you can actually see what user caused which traffic using what program and when it happened.
All this information is acquired automatically so the minimal configuration necessary is to tell dragon where it can find its MySQL database.
Enhancements:
Features:
- cleanup on CTRL-C
- add patch for Linux Kernel 2.6.17.7
- for now, graphs are disabled in the webfrontend
- webfrontend has now Total, User and Program tabs
Bugfixes:
- forgot to close a filedescriptor fixed
- use leading zeroes on port numbers in messages about connections that no longer exist
- really fix wait for next minute

SMTPGuard is a tool which controls the flow of email traversing an MTA (Mail Transfer Agent). It is designed to be used on an SMTP server for incoming mail, and currently supports postfix.
SMTPGuard was originally created to meet the needs of Internet Service Providers (ISPs). ISPs typically receive tremendous amounts of email from their local (user) network.
Within a wide variety of users, some are spammers, many unknowingly have virus infected PCs; each of these can send large quantities of mail through the ISPs SMTP (Simple Mail Transfer Protocol) servers.
This is especially a problem for ISPs who are connected to their users via high speed lines such as fiber or ADSL. SMTPGuard was developed to prevent SMTP servers from being overwhelmed by unexpected spikes in usage from specific (often malicious) users.
For a large ISP, their only problem isnt just with overloaded incoming SMTP servers. SPAM will also be queued on the outgoing server (perhaps the same server) for delivery to the Internet.
Because the mail is SPAM it will likely bounce, then double bounce putting extreme load on the outgoing server and its queue. smtpguard is designed to stop this type of extreme load by stopping floods of mail at the gate (incoming server).
SMTPGuard is point based. Each time a client connects to the SMTP server, SMTPGuard adds points according to the rules file. SMTPGuard uses information acquired during the SMTP session, adds points according to the rules file, and finally takes actions based on its settings. For example, the information below is used:
- Remote IP Address
- Character string provided by MAIL FROM command
- Character string provided by RCPT TO command
The following actions can be taken:
ok - white list
wait - delay processing
reject - reject messages
mail - send alert email to administrator
log - output message to log
delete - delete record in database
Enhancements:
- postfix/flexguard.c: remove word flexguard. use smtpguard instead. rename filename to postfix/smtpguard.c
- postfix/Makefile.am: rename flexguard -> smtpguard
- configure.in: 1.1.1
- rename FLEXGUARD_{CFLAGS,LIBS} -> SMTPGUARD_{CFLAGS,LIBS}
- smtpguard/Makefile.am,postfix/Makefile.am,test/Makefile.am: Ditto
- debian/postfix-smtpguard.files: added
- README.postfix: added

IRCM is a webbased Incident Registration and Configuration Management tool that supports helpdesk operations in an ICT-environment.
With IRCM, helpdesk agents can register and dispatch service calls. These calls can be related to agents, customers, SLA-defined activities, devices, incoming or outgoing mail and timers. Service levels are guarded depending on call type, call status and service window.
The customers infrastructure is managed in the configuration management module, providing full 2D-tracing through related devices.
IRCM is protected by GNU/GPL and is available for download on this site.
IRCM supports multiple customers, helpdesks, Service Level Agreements, mailboxes etc in one database. If multiple databases are used (e.g. to separate customer data) the user can switch dynamically between databases within the browser window.
For configuration management, a black-box approach is used. This maximizes flexibility in modelling the customer infrastructure. The only predefined (system) entity is the user, all other entities and their properties are defined per customer. Hierarchical relations between configuration items can be displayed in a 2D overview.
A valuable aspect of IRCM is that you dont have to use the features summed up here. If you want to use the Configuration Management module as an address book and want Incident Registration to be a todo list, you wont be punished with overhead.
Main features:
- Multiple customers
- Multiple Service Level definitions (incident types, resolv time, SLA defined activities)
- Multiple users and customizable incident queues.
- IMAP based mail (Exchange)
- Multilevel authentication, authorisation and logging
- Report designer module
- 2D-trace based patching
- Bulk data import and export
- Client Link Module (real time events, timers and messaging)
- Callcenter linkable

KNetLoad is a Network Load Monitor applet for Kicker. You can monitor how many interfaces you want, and for every interface it will show you two graphs, one for incoming and one for outgoing load.
From version 3.0 you can now monitor remote SNMP interfaces, knowing the interface number (work in progress naming), and you can configure every interface in a different way.
The "stable" 2.3 version is no more supported, as 3.0_alpha1 should be stable enough, and it should fix a lot of problems.
Enhancements:
- Applet mode, instead of standalone application.
- Ability to monitor more than one interface at a time.
- Different settings for every interface.
- SNMPv1 support for monitor remote interfaces.
- New, faster, parsing code for both 2.6 and 2.4 kernels.
- Settings dialog with all the settings for the applet.

GNU ccRTP is an implementation of RTP, the real-time transport protocol from the IETF (see RFC 3550, RFC 3551 and RFC 3555). ccRTP is a C++ library based on GNU Common C++ which provides a high performance, flexible and extensible standards-compliant RTP stack with full RTCP support. The design and implementation of ccRTP make it suitable for high capacity servers and gateways as well as personal client applications.
In designing ccRTP, we have taken into account that RTP has been defined as an application level protocol framework rather than a typical Internet transport protocol such as TCP and UDP. Thus, RTP is hardly ever implemented as a layer separated from the application.
Consequently, RTP applications often must customize the adaptable RTP packet layout and processing rules, timing constraints, session membership rules as well as other RTP and RTCP mechanisms. ccRTP aims to provide a framework for the RTP framework, rather than being just an RTP packet manipulation library.
Support for both audio and video data is also considered in the design of ccRTP, that can do partial frame splits/re-assembly. Unicast, multi-unicast and multicast transport models are supported, as well as multiple active synchronization sources, multiple RTP sessions (SSRC spaces), and multiple RTP applications (CNAME spaces). This allows its use for building all forms of Internet standards based audio and visual conferencing systems.
GNU ccRTP is threadsafe and high performance. It uses packet queue lists for the reception and transmission of data packets. Both inter-media and intra-media synchronization is automatically handled within the incoming and outgoing packet queues. GNU ccRTP offers support for RTCP and many other standard and extended features that are needed for both compatible and advanced streaming applications.
It can mix multiple payload types in stream, and hence can be used to impliment RFC 2833 compliant signaling applications as well as other specialized things. GNU ccRTP also offers direct RTP and RTCP packet filtering.
GNU ccRTP uses templates to isolate threading and sockets related dependencies, so that it can be used to impliment realtime streaming with different threading models and underlying transport protocols, not just with IPV4 UDP sockets. For a more detailed list of ccRTP features you can have a look at the programmers manual.
At its highest level, ccRTP provides classes for the real-time transport of data through RTP sessions, as well as the control functions of RTCP.
The main concept in the ccRTP implementation of RTP sessions is the use of packet queues to handle transmission and reception of RTP data packets/application data units. In ccRTP, a data block is transmitted by putting it into the transmission (outgoing packets) queue, and received by getting it from the reception (incoming packets) queue.
Main features:
- Highly extensible to specialized stacks.
- Supports unicast, multi-unicast and multicast. Handles multiple sources (including synchronization sources and contributing sources) and destinations. Also supports symmetric RTP.
- Automatic RTCP functions handling, such as association of synchronization sources from the same participant or NTP-RTP timestamp mapping.
- Genericity as for underlying network and transport protocols through templates.
- It is threadsafe and supports almost any threading model.
- Generic and extensible RTP and RTCP header validity checks.
- Handles source states and information as well as statistics recording.
- Automatically handles SSRC collisions and performs loop detection.
- Implements timer reconsideration and reverse reconsideration.
- Provides good random numbers, based on /dev/urandom or, alternatively, on MD5.
There are several levels of interface (public interface, public or protected inheritance, etc) in ccRTP. For instance, the rtphello demo program distributed with ccRTP just uses the public interface of the RTPSession class and does not redefine the virtual method onGotSR, thus what this program knows about SR reports is the information conveyed in the last sender report from any source, which can be retrieved via the getMRSenderInfo method of the SyncSource class.
On the contrary, the rtplisten demo program redefines onGotSR by means of inheritance and could do specialized processing of these RTCP packets. Generally, both data and control packets are not directly accessible through the most external interface.
All this functions are performed through a few essential classes and types. The most basic ones are the enumerated type StaticPayloadType, and the classes StaticPayloadFormat and DynamicPayloadFormat.
The most important ones are the classes RTPSession, SyncSource, Participant and AppDataUnit, that represent RTP sessions, synchronization sources, participants in an RTP application, and application data units conveyed in RTP data packets, respectively.
When using ccRTP, both sending and receiving of data transported over RTP sessions is done through reception and transmission queues handled by the RTP stack. In the most common case, a separate execution thread for each RTP session handles the queues. This case is the threading model that we will generally assume throughout this document. Note however that ccRTP supports other threading models, particularly ccRTP supports the use of a single execution thread to serve a set of RTP sessions. It is also possible to not associate any separate thread with any RTP session, manually calling the main data and control service methods from whatever other thread.
The basic idea for packet reception with ccRTP is that the application does not directly read packets from sockets but gets them from a reception queue. The stack is responsible for inserting received packets in the reception queue and handling this queue. In general, a packet reception and insertion in the reception queue does not occur at the same time the application gets it from the queue.
Conversely, the basic idea for packet transmission with ccRTP is that packets are not directly written to sockets but inserted in a transmission queue handled by the stack. In general, packet insertion and transmission occur at different times, though it is not necessary.
In order to use ccRTP, you must include the main header (#include < ccrtp/rtp.h >. Two additional headers are provided by ccRTP:
#include < ccrtp/rtppool.h
Classes for pools of RTP service threads.
#include < ccrtp/rtpext.h >
Classes for RTP extensions which are not mature yet.
You must also link in the library, currently ccrtp1.
Enhancements:
- Brand new support has been introduced for Secure RTP Profile (srtp) as per RFC 3711.
- This release also supports a new add-on package, libzrtpcpp, that directly offers native zfone (zrtp) compatible encryption capabilities to Common C++ RTP based applications.
- This is the first softphone client to use both Common C++ RTP srtp and zrtp support.

Hardware Monitor is a multi-purpose, beautiful system-monitoring applet.
The Hardware Monitor applet is an applet for the GNOME panel which tries to be a beautiful all-around solution to system monitoring. It also strives to be user-friendly and generally nice and sensible, integrating pleasantly with the rest of your GNOME desktop.
Includes different viewers, including a flame effect, allows multiple devices to be monitored in the samme applet, uses smooth updating, polished graphs, clean HIG-compliant interface.
Main features:
- A graphical view where each monitor is represented by a (time, measurement) colored curve
- A bar-plot view with a horizontal bar per monitor
- A column view with a column (time, measurement) diagram for each monitor
- A textual view which simply lists the monitors and the currently measured values
- A flame view which produces spiffy flames, the sizes of which are determined by the values of the monitored device
And the applet supports monitoring the following hardware characteristics:
- CPU usage (all CPUs, or one at the time) - niced background processes such as SETI@home are automatically ignored
- Memory usage - cache and buffers are automatically ignored
- Swap usage
- Load average
- Disk usage (or disk space free)
- Network throughput (Ethernet, wireless, modem, serial link), either incoming or outgoing or both
- Temperatures from internal sensors (e.g. system board and CPU temperatures)
- Fan speeds from internal sensors